• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

RPM packager

Started by minou, 2011.08.28, 07:35:09

Previous topic - Next topic

Do you want an RPM/YUM implementation for OS/2 that uses the Unix/Linux "Filesystem Hierarchy Standard" (/home, /var, /usr, /etc..)?

Yes
14 (41.2%)
No
18 (52.9%)
I don't know
2 (5.9%)

Total Members Voted: 0

Fahrvenugen

Quote from: dmik on 2011.09.01, 03:42:28
Fahrvenugen, RPM is capable of replacing all of them.



I'm sure RPM could replace all of them, just like Warpin can replace ZIP, the original IBM installer, and Feature Install (at one point Warpin's goal was to replace all the old installers).  But the reality is that unless someone goes through and repackages all this stuff in RPM (which would seem a silly and pointless waste of time IMHO), it won't replace all of them.  RPM/YUM will just become yet another installer you have to put on your system just so you can install the stuff packaged with RPM. Does that mean I'm rejecting RPM / YUM?  Not at all.  I'm just pointing out that it what it'll mean to me, as someone who uses and supports OS/2 / eCS.

Quote from: dmik

What you say about OS/2 and its in-the-middle approach was true in the past. It cannot remain like that now. (Well, it can, if you install it on an old 486 PC, load it with old programs made in 1992 and will *not* ask us about modern software and all the fish). You cannot also remain an expert in the changing world if you don't change with it. The compexity is being constantly increased; if you want to deal with it, you have to move to a next level. Or leave it.

I can't speak for others, but part of the reason I keep OS/2 around is because of this approach (and yes, I also use Windows and Linux on a daily basis).  If I want the latest and greatest cutting edge stuff, Linux and / or Windows fits the bill.  But when I want something that works well - as well as it did 10 to 18 years ago and have it use some of the same standards as it used back in 1994 when I installed my first copy of Warp 3, I get that with OS/2.  Furthermore I know that when I get OS/2 or eCS up and running, it'll generally "just work" (true, it might take some time to get it up and running depending on hardware, but once it is up my experience has been that things just keep working...  one machine I set up to run some specific tasks recently ran for over 2 years without so much as a reboot, until a power failure and bad UPS battery brought it down).

I know this feedback has little to do with porting current software and such.  But it can perhaps explain why there is so much discomfort with this proposal. 

dmik

#76
Fahrvenugen, the idea of having RPM in the first place is to eventually repack everything with it. From your perspective (running OS/2 stuffed with old programs which just work for years), this will be a waste of time indeed. From our perspective (trying to give OS/2 the future), this is a must do.

Thank you for your explanation. We know about your discomfort and what it is caused by. What I'm trying to explain here in turn is that we have a different focus (the future) and this is what brings misunderstanding when it collides with your focus (the past). Leaving you "comfortable" means not bringing new software to OS/2, you got this point right.

OTOH, bringing this new software doesn't mean OS/2 will become less stable than it already is. This depends on the software itself, not on the fact if we have FHS or not. Yes, it may become harder to understand what's under the hood, but that's the price you have to pay for the increased functionality and comfort.

miturbide

dmik, you are right, maybe developers are happy with the Linux FHS and the FHS is not meant for the users.

But FHS is not friendly to the end user and an Operating System has to be friendly to the user. It will be better to adapt RPM to the currently eCS-OS2 file system structure (or improve the eCS-OS2 standard if you think something is missing). I don't care if the solution will be incompatible with FHS, because OS/2-eCS is not Linux, it does not have to be complaint with an standard that creates more complexity to the user.

Do you think that technical users want to add more directory mess to the eCS HDD, like the Ubuntu screenshot I showed before?

I can not agreed that to help developers with the program packaging and help the users to install all software pre-requisites at once you had to create more directory mess on the eCS HDD. A more intelligent solution has to be offered.

Windows does not use FHS.
Do you see Windows developers complaining that Windows doesn't use FHS? no.
Do you see Windows users complaining that is hard to install software on Windows? no.

By making RPM using FHS and making software installers that requires only RPM you are facing the risk of creating a software installer that no user want to use. What is the meaning for a developer to create a software that nobody wants to use?

The "Developer Zone" is not worthy for me if there is no user that want to use the programs. The developers should find an intelligent solution that will interest the users, instead of trying to convince them that it is what they consider "the best solution" (in this case FHS).

Please notice that my position is against using FHS directory structure under OS/2-eCS. If RPM will include a better solution instead of creating a directory mess, it will be welcome.

dmik: Do you think that RPM will be useless without using the FHS standard?
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

dmik

#78
Quote from: miturbide on 2011.09.01, 20:49:23
Do you think that technical users want to add more directory mess to the eCS HDD, like the Ubuntu screenshot I showed before?

Do not look at the root directory in Ubuntu. What is the problem? Why are you keeping doing this if it makes you hurt?

Quote
Windows does not use FHS.

I don't use Windows. Windows is unmanageable. Mostly because it has nothing like RPM. However, I'm being frequently asked by some friends to reinstall their copy of Windows every several months because it is screwed, or because there is a virus, or because it is screwed and there is a virus. If they succeed in convincing me to help them I install them Ubuntu (or suggest to buy a Mac). Even my blonde girlfriend has Ubuntu installed and feels pretty much happy with it (it's been working for years on her notebook w/o any maintenance, just like OS/2 actually). So Windows is a bad example.

Quote
dmik: Do you think that RPM will be useless without using the FHS standard?

I can only repeat again that RPM has noting to do with FHS. Without FHS we will have to a) invent our own FHS and b) maintain a huge amount of OS/2-specific patches in every program ported from Linux which will be the constant source of bugs. Neither of these things will make programs better serve the user's needs. They will only be sucking our resources resulting in less software and bigger release delays. This makes no sense. Please stop aching and better learn to think different.

ivan

The more I read of this the more concerned I am becoming.

At the moment it appears that the developers want to dictate the file system layout - this would be fine if they thought about what they are trying to do and applied it to the real world where people have to earn a living.

Behind me I have a rack of servers and out in the office and works are a rather large number of workstations all using OS/2.  Beside me I have a server that is used for testing all software that is to be added to the system and I am typing this on a workstation that is also used for testing software.

Now this is where I see a very large problem with the RPM/YUM installer - I need to know where every part of each program is, I don't need the hassle of having to search several tetra-bytes of hard disk to find it.  If it passes all the tests all I want to do is zip up ONE top directory and use that file to transfer to all servers and workstations, unzip it and they are up and running.  Also it shouldn't be on the boot partition because that is as small as we can get it.  The only additions allowed on the boot partition are such things as the QT4 runtime, java runtime etc.  There are a few exceptions but they are just the ini files for programs such as BlueCAD.

I don't really care what goes on in the subdirectory structure under the 'program name' directory and that directory must be the top directory for the program and be able to be placed where I want it - be it tools, graphics, cad etc.

If a program doesn't meet those conditions someone has to present a very very pressing case for it to be tested and deployed and if it tries to insinuate itself into the boot partition it will never be used unless we can persuade it otherwise.

That may sound hard but I have a business to keep running and making money.  Anything that messes with the computers has the potential to stop the business and is so discarded out of hand - we aren't playing with computers, they are essential to the business.

ivan

miturbide

Quote from: dmik on 2011.09.01, 22:10:04
This makes no sense. Please stop aching and better learn to think different.

dmik, why do you start with this personal attacks again? You can not dictate someone from the community to start thinking different. Nobody is dictating you how to do your stuff. You are asking for feedback, and that's what you get. Not all the people will think like you and people may rant and disagreed with you.

You are here lobbying yhe idea to use FHS without showing any real benefit to the User, just saying that the Developer dictate what the User needs. I disagreed with that. No matter how much you attack the people that think different from you, it will not change their mind till you show something interesting.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

dmik

ivan, thank you for the feedback.

Yes, RPM will dictate you the FS layout for all system components it manages (and for applications by default, unless the application developer makes the application relocatable and enables this function when packaging it with RPM). The dictatorship in the area of some system components is what you already have though.

If you need to know where every part of each program is, it is very simple to do in RPM (rpm -ql <program_name>, this will give you the exact listing of all installed files with their full paths).

If it passes all the tests and you want to transfer it to all servers and workstations, you don't need to have the hassle with ZIP. You only need to run |yum install <program_name>| on these machines.

Regarding the boot partition. There may be only one system UNIXROOT tree (located on any partition, not necessarily the boot one) where all system components and programs that not support relocation will live. This means that you cannot freely select the target installation directory for most programs distributed as RPM (this is an intentional decision of this distribution model). However, it is always possible to create a custom RPM package even if the original one doesn't support relocation -- provided that the program itself can work from any directory. This doesn't require too much work (not more than creating a ZIP if you have some minimal RPM experience). You can then put the custom RPM to your internal RPM repository and install it with |yum install <program_name>| on all machines as well.

You say the right words about the business, but please don't forget that we are primarily focused on general use that covers the most common scenarios. Any specific use case may require specific actions. But RPM itself is flexible enough, it's not a stopper here. I actually think that your environment will benefit from it more than you probably think now, because of its great automation capabilities.

lewhoo

dmik,

There is a problem accessing previous posts in this thread, but I remember you asking me, why would I want to decide where to install a program. There are a couple of reasons.

1) Order. Order as I see it - usually you do not invite anyone to decide where to put things in your room. And even if you do at the stage of building your house, you choose from many projects. I browse through the file structure often,on OS/2, linux, windows. I know that there are plenty of windows user who never use any folder from hdd, but they use to pay other people for any simple maintanance. OS/2 users are not like that and they won't be - face it.

2) Ability to change order. I like to have my apps in different directories depending on their purpose. Dev, internet, graphics, etc. This is my personal idea. You may ask why would I want to access an apps dir? First of all for changing configuration files, cleaning rubbish (oh yes, current apps,includingthoseon linux, still produce lot's of rubbish) etc. You may say that on linux configuration files are in . dirs in home, not in root FHS. Yes,they are and... all the directories are there, no categorization, no use of an idea of structure of directories createdby user invented so many years ago. It's so archaic and so messy! Finding anything in this mess is a pain and working with all this is a pain. My home directory on linux is a mess and I did nearly nothing to make it so ;) My whole directory structure is a mess, I did nothing to make it so, but you just say it should not interest me. Well, it does.

3) Safety. Backing up with organized (and I don't call linux FHS organized) directory structure is much easier. Keeping different files on different partitions is much safer. It is still not so uncommon to have an FS error. In this way I can attempt to minimize loses. Currently - I am afraid that with FHS introduction no more.

To summarize - I do browse program directories. It's not my hobby, it is still a thing that you have to do if you want to do anything more advanced than watching movies. When I do it on OS/2, I enjoy it. When I have to do it on linux, I curse.

And to answer your recent posts. You write:

"From our perspective (trying to give OS/2 the future), this is a must do."

Well, it is nice to have any new programs on OS/2 (QT makes it possible , however, I'd be happy if we had a native-controls library available to write OS/2 native software,library such as wxWidgets). It's nice to have other solutionsfrom other OSs that make eComStation living. But you are coming close to crossing a line. A line where eComStation will have mostly some linux features and not many unique features. Linux ported software on linux-like FHS with linux like approach (dumb-user or admin)? What is there left to stay with eComStation then? WPS is not everything. If you will not use some of your developers time to preserve OS/2 uniqueness, you may very well kill OS/2. I know that that is not what are you willing to do and I hope that you will not do that.

"I can only repeat again that RPM has noting to do with FHS. Without FHS we will have to a) invent our own FHS and b) maintain a huge amount of OS/2-specific patches in every program ported from Linux which will be the constant source of bugs. Neither of these things will make programs better serve the user's needs. They will only be sucking our resources resulting in less software and bigger release delays. This makes no sense. Please stop aching and better learn to think different."

Well,you know what is a way to have no release delays, no bugs from additional patches, no additional sucking of resources? I have a perfect answer: use linux! It seems, that you have to learn to think different. I know that there is not enough developers manpower, but you have to keep in mind that porting to a DIFFERENT OS takes time! Again - either you preserve OS/2 uniqueness keeping in mind that porting will be more painful, or you are coming close to a line where you will kill a reason for using eComStation.

Most if not all of OS/2 community are power-users. We know what our system is about and we have well justified habits and needs. You can make a simple poll stating, what changes you'd like to make to eComstation and what of those users are willing to accept. Then, of course, looking at the results you may complain about dumb users. But these dumb users won't take everything that you will serve them.

dmik

miturbide, come on, I am not attacking you. I'm trying to say that when you refuse the new ideas you don't give me the facts, you give me the emotions. Emotions are not good for making conclusions. Please read what e.g. Ivan just posted. A bunch of particular practical concerns. And none of them starts with "I don't like it, my eyes hurt" or "I hate the Linux mess".

For some reason, you just don't want to see what benefits RPM gives you. This may be my fault, but this may be your fault as well. I will keep explaining.

P.S. Learning to think different is always good. I'm serious. Everybody should suggest it to everyone.

miturbide

Quote from: dmik on 2011.09.01, 23:48:10
For some reason, you just don't want to see what benefits RPM gives you.

Like I told you before, I know the limitations of WarpIn and I understand that RPM is a more powerfull tool. My complain is using the same Linux directory structure (FHS) on OS2-eCS. FHS gives no real benefit to the users. Other OSes do not use FHS and works fine. FHS looks messy. FHS is hard to understand. ... and the rest of emotions. (which I don't think that is bad to express)
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

melf

Is it to be understood that the dictated way also is the way Mensys want to go with eCS? In all cases, they are the big players in this game.
/Mikael

dmik

#86
miturbide, you say "FHS gives no real benefit to the users". Yes, this is true. We agree on that. Where is the problem?

Regarding "other OSes not using FHS", you are speculating. There is only one OS not using FHS, all other OSes (a dozen of actively used ones) do use it and work not just fine but often much better than that OS. Again, what is wrong with that?

melf, please do not speculate on words, either. This is a bad practice. I can't speak for Mensys, actually. When I say "eCS will be..." I express the plans of the group of developers. But it will not surprise me if Mensys also wants to have a better software management infrastructure.

miturbide

Quote from: dmik on 2011.09.02, 00:27:33
Regarding "other OSes not using FHS", you are speculating. There is only one OS not using FHS, all other OSes (a dozen of actively used ones) do use it and work not just fine but often much better than that OS. Again, what is wrong with that?

dmik: Using FHS will not make OS2-eCS run better an be more stable. FHS it is not what makes an OS more robust. Windows does not use FHS and runs fine. Linux is more stable than Windows, but it is not because of FHS.

melf: thanks for you idea. 

I'm stopping my comments right now.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

djcaetano

 dmik,

  I really *do* understand the reason to incorporate FHS into the system so it would simplify porting and management. And, in fact, as I had already said before, I *do* support it. I think it is perfect using RPM and YUM to install and maintain ports of Unix applications on eCS, all stored in a single FHS. It is a mess for the end user? Well, it is a mess in the original system (Linux), the developers and porters don´t have to be responsible to "correct" this... even more if the maintainers of the code do not accept our patches in the main tree because our system is "so different".
  Kudos for creating a Linux FHS and installing with RPM and YUM if this will bring more up-to-date software from Linux.

  What I *do not* understand is WHY convert the entire operating system into this FHS mess?
  No matter what is being ported, the base operating system and utilities will be ALWAYS specific software (unless there are secret plans to replace OS/2 base by a Linux base). No change on FHS will allow Linux drivers and installable filesystems to work "automagicaly" on eCS.
  Specific OS/2 programs will never be ported to Linux and creating an "eCS integrated Linux port" usually requires much more effort than converting file structures (like adding WPS integration and so on).
  Also, all the old software - I do not plan to let good old software bit the dust - will be installed in the same old fashioned way. FHS will have to live side by side with "old" organization.

   Most of die hard OS/2 users are fond to it because it DO preserves the users investment... many of the years of knowledge about the operating system will be wasted if all of a sudden every piece of software has been moved elsewhere. It may seem weird to you, but if I´ll have to "learn"  the entire Operating System again, maybe it´s time to learn something current, up to date and that is able to run on my i7 generation 2 (by the way, eCS doesn´t boot on it, and I am sure it´ll not boot even if ALL Linux applications have been ported to eCS 3.0 with Unix FHS).

   The only thing I think it is good for the general user on FHS is the "backup easiness". OTOH, everything else is just crap and mess. Spread application files into several directories is, on my PoV, far from a good idea, and it is an OLD idea when all the applications were composed of and executable and a help file. Oh, it makes development so easy?
   Remember, directories purpose should be to help the user on *organizing* its files, not to put handcuffs on them.

   Regards,
   djcaetano

dmik

lewhoo, if you want your own order and manual control in the system area, why do you need WarpIn? It looks like an obstacle in this process too (as it may and will dictate you some things). However, if you like order, there is still a way to get things look like you want, even with RPM and FHS. You have WPS, you may organize things there according to your preference. This is just another level of abstraction where we offer you to move. One idea behind RPM is that it sorts things out for you, so you don't need to care about them any longer -- they will work without you being looking at them in File Commander.

I assure you that porting the current software to OS/2 will remain painful enough regardless of whether we use FHS or not. This is due to bugs in the native components that will never be fixed and due to the lack of the documentation that will never be written. The original OS/2 directory structure and the way how people are used to manage software may be unique but this is not what we think is worth being preserved in order to keep the OS/2 spirit alive.

miturbide, your conclusions are naked. I think you know yourself why. Thanks for the feedback though.

djcaetano, some of your points make sense, but see below. I'm open to discuss things further, but only if we go to the technical level where the practical purpose dominates, not the old habits. Regarding FHS and the entire system, it will probably shock you but this indeed implies replacing the OS/2 core utilities with the Posix ones (e.g. sh.exe instead of cmd.exe). The OS/2 ones will stay too of course (for the compatibility reasons), but in a separate command prompt.

Regarding the high learning curve, the idea is (I repeat) that our model assumes that you don't have to know the command line at all (except for 'yum install', but this is a temporary exception). Regarding the boot problems, drivers is a completely separate area, I don't get why you mention it. Luckily, we still have a few developers working on them, so there is a chance to have it running in native on the current hardware.

To all three of you. The discussion shows that we have two distinctly different visions of the OS/2 future. You don't like and don't need things that we do. I see no problem with that. Just don't use what we offer. We can't and we don't want to force you. Don't install RPM, don't let us create the FHS mess on your system, don't use Qt and Qt applications, don't use messy Paul's ports. Do things as you want them and be happy -) The future will show whose position is more realistic.