Poll

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

Author Topic: RPM packager  (Read 25102 times)

miturbide

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1154
    • View Profile
    • OS2World
Re: RPM packager
« Reply #30 on: 2011.08.30, 03:10:38 »
Pete, this is a bug we have with Joomla and SMF Forum integration, you need to access direcctly to the forum thread.
http://www.os2world.com/forum/index.php/topic,3701.msg20882.html

Or you can visit the forum directly.
http://www.os2world.com/forum
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

miturbide

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1154
    • View Profile
    • OS2World
Re: RPM packager
« Reply #31 on: 2011.08.30, 03:18:12 »
dmik, I tried again RPM and YUM. rpm-yum-bootstrap-1_3.wpi

The Linux file and directory structure that RPM/YUM are creating it is not good for me. I am not used to that structure, Im not a Linux user. I personally don't undestand it and I see it as mess inside the hard drive. All the RPM/YUM files should be installed inside a directory /Programs and the programs that YUM install should also be in /Programs.

RPM/YUM should be adapted to use the OS/2-eCS directory structure.

That is my first problem using RPM/YUM.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

David McKenna

  • Full Member
  • ***
  • Posts: 130
    • View Profile
Re: RPM packager
« Reply #32 on: 2011.08.30, 04:22:12 »
dmik,

  Thanks for all the fantastic development you have done for eCS. What I want most of all for eCS is updated system components and more apps! Anything that could make that happen faster, better, cheaper is a plus as far as I am concerned, so I am all for RPM/YUM. It's clear to me a lot (all?) of those things will come from Linux so it makes sense to use it. I have tried YUM and it did seem easy to use once I got used to it. That said, I do think it would be a good idea if a GUI was available to make the transition to using it smoother for users already accustomed to GUI installers for many years now. It would be great if the only thing a user ever typed on the command line was 'YUM install <YUMGUI>'. Even better if the install did it for you ;-)

Regards,

Dave McKenna

abwillis

  • Sr. Member
  • ****
  • Posts: 325
    • View Profile
Re: RPM packager
« Reply #33 on: 2011.08.30, 04:26:47 »
The biggest problem I have had with RPM or Apt is that I have no idea what it has put where so when it doesn't work it is a huge pain to figure it out.  Actually, I am including in the not working pile is the software that I have installed and then can't figure out how to launch because I have either no idea where it put the blasted icon to launch it or in cases of no icon being created no idea what command to run to launch it.  Ubuntu with its system was easier to get that information I have found than it is from RHEL as the Ubuntu at least had an interface in the installer to show what had been installed where (haven't found that in RHEL yet).  For me the ease of installation has made things somewhat more complicated in that it doesn't give me the option to install into a directory that I specify so that I then have to spend more time finding that out when something is not working.  Overall, it may actually be better to just let it lump everything together where it wants to go but I can't count the number of times I have ended up hating Linux based largely on the fact that I don't have the control that is available even on Windows much less eCS\OS/2.  
I have to say, I think that the whole GUI vs. typing a few characters argument is a bit perplexing.  Having installed much software on OS/2 via command line (usually creating a directory and unzipping files) and had many people complain that that is not the only way I don't see the reason to fuss over command line YUM vs. a GUI.  On Linux I generally prefer to use the command line install if I know the program I am looking for... the GUI is good when I know I want a type of software but unsure which particular one I want (or an exact name).  While I can understand someone may prefer the GUI over the command line install I think it is a bit premature to worry about it as a someone likely would build a GUI frontend for the command line and a short time of having to type (or copy and paste a command) truly is simpler than our current installation methods.

lewhoo

  • Jr. Member
  • **
  • Posts: 71
    • View Profile
Re: RPM packager
« Reply #34 on: 2011.08.30, 09:09:57 »
dmik,

I think I can make a few statements about what I would like OS/2 version of yum and rpm to be:

1) Simply decide where I want to install my software
2) Know where the software is installed (in case of some default locations)
3) All options and possibilities accessible by GUI installer,no more complicated than WarpIn
4) GUI installer always compatible with rpm/yum
5) Advanced mode (in gui, not with 1024 bytes of command line) : choosing dependecies, where they are going to be installed, where the rpm should look for them, if rpm should extend path/libpath in config.sys,etc.

ad. 4. My experience with linux GUI frontends to software (in this case not yum guis, but other) is that often they are developed separately and finally when you want the newest vbersion of software you have to mess with command line anyway. A think that we have managed to avoid with OS/2 for years, at least in most cases

ad. 5. If I want my installed package to use only one version of dll that is not available to the other,etc. I'd like to tell rpm to install it in a different location and so on.

And to explain my linux experience:

1) Directory structure on linux, or at least on Fedora which I am used to, is a complete mess. Software can be installed in plenty of places,according to what the developer of package likes. When you finally have to compile software or untar.gz it and place it somewhere manually, you often have to look for an older version, edit script in path calling the real executable, etc. - quite often with new releases of firefox/thunderbird not given in an rpm or any nonstandard builds.

2) The dependencies are often a mess - you have a software that wants older vesion of lib s to work and won't work on newer. Either you have to stick with older versions of libs (and cannot use newer software), or resign from using it, or come through a pain of manually configuring and installing the package. It always seemed much easier for me on OS/2, maybe not only because of a much superior and clear OS/2 directory structure, but because somehow most of OS/2 libs are backward compatible and OS/2 programming was,at least up to date,much more responsible than linux programming.

3) As I said before - command line-gui connection is often broken on linux. Even more, linux command line arguments are often a mess, switches are cryptic, etc. This forces the situation: you can be a dumb user waiting only for new packachges available via yum and praying that everything will work out of a box (and all of us know, that it is not always the case) or you suddenly have to become an admin with knowledge much bigger than I would like to possess. Please, please, please, don't make eComStation like that!

diver

  • Full Member
  • ***
  • Posts: 153
    • View Profile
Re: RPM packager
« Reply #35 on: 2011.08.30, 10:56:44 »
Hi all,

we know there is a big RPM/YUM fear. And we know (at least we think we know) what a user needs (Remember: This is like demanding to optionally change the position of the engine  in a car, you simply should not want to do that!).
We as developers are the last who wants users not using our software. But we need to decide once if a decent installer can do our work easier. And we know RPM/YUM can do it. That said we also told that we will deliver ZIP's for all our software. This means you can install the ZIP if prefered. Or if a user steps forward and generates a WPI for what we deliver it's really no problem. We will try to help on every question he has. We can't do that also, as there is just not enough manpower on developer side. If we would be a hundreds, then we could do way more. But i guess we are a handfully only. At least my projectteam is very small. And from a manager point of view i also need to take care on the costs. If a RPM/YUM based installation costs me half (or even less) than a WPI based i have to decide on the less costy one. Of course we could invest more on a WPI based installer and deliver less software. But this would be a wrong decision in my opinion.

So if a user wants to step forward to work on a WPI from our software please write me a mail.
Thanks for all your time and keep smiling

regards
Silvan

Pete

  • Hero Member
  • *****
  • Posts: 865
    • View Profile
Re: RPM packager
« Reply #36 on: 2011.08.30, 13:01:34 »
Hi Silvan

You may be confusing the word "fear" with the phrase "dislike and distrust" which those of us with some linux experience have expressed - and: Why should I not want to change the position of an engine in a car? If I think I know better but it all goes wrong then I also know how to revert to the standard position  :-)


Regards

Pete




« Last Edit: 2011.08.30, 13:10:38 by Pete »

Pete

  • Hero Member
  • *****
  • Posts: 865
    • View Profile
Re: RPM packager
« Reply #37 on: 2011.08.30, 13:07:42 »
Hi Martin

Pete, this is a bug we have with Joomla and SMF Forum integration, you need to access direcctly to the forum thread.
http://www.os2world.com/forum/index.php/topic,3701.msg20882.html

Or you can visit the forum directly.
http://www.os2world.com/forum


Both the above links lead to the same webpage - http://www.os2world.com/forum/ - despite the different urls.

It is not possible to load page1 of this thread by navigating to OS/2 - Technical > Setup & Installation > RPM packager and selecting page1; that gives the same error message as reported previously.

Regards

Pete

dmik

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: RPM packager
« Reply #38 on: 2011.08.30, 13:34:43 »
Pete, yes, eventually all (or almost all) software will be distributed as RPM. From the perspective of creating RPM packages, there are no problems at all: you don't need the source of the program, you just need binaries and understanding what environment the application needs.

miturbide, OK, I understand you. You want to have a recognizable picture of directories in the root of your drives and you don't want to use the command line. It's your vision and I respect it. Your main problem, however, relates to FDS, not to RPM. There is a good reason for choosing the Unix directory structure (I can explain if you ask me) and this is something that cannot be changed because that would require too much effort and would not give any practical benefits to end users. The idea of the new approach of the software management (which RPM is part of) is that the user should not care about such things as system directories; the only thing he should care is choosing a hard disk big enough to include the software he needs when installing RPM itself for the first time.

Think of the "usr" directory as if it were "Programs". It doesn't affect the behavior of applications; it's just a name. If you speak about Mac OS and their way of installing applications in separate directories inside /Applications, then I must say  that this approach is not suitable for OS/2 because we don't have a necessary level of control over the OS itself to make it work well. Instead, we chose to go the way of completely hiding this level of technical detail from users (something that Apple has actually already succeeded with in their iOS products).

David McKenna, thank you. You understood it right about the software coming mostly from Linux. This is the fact we all have to admit. Our intention though is to make the task of managing this software as simple as possible for end users. RPM is a step towards this direction. The GUI for it is necessary and will come later. Please be patient and understand that the yum command line is an intermediate step needed because WarpIn is not suitable and RPM GUI is not there yet.

lewhoo, thank you for describing what you would like to see, here are my comments to your numbers.

 1. Why do you want to decide what directory you want to install your software to?
 2. You may easily find where RPM has installed all files of the package <pkg> by doing rpm -ql <pkg>.
 3. The GUI interface to YUM/RPM will be available later.
 4. -- // --
 5. Choosing dependencies is done automatically as well as changing the system configuration (path/libpath/WPS), no user interaction is needed here. The GUI will show you an overview of changes before applying them though (the command line already does that). Software repositories will be configurable from the GUI once it's there. For now, the default (pre-configured) repository will be enough for 99% of users.

ad.4. Understandable, but as you note yourself this problem is not specific to RPM. It is a general problem of program A depending on an outdated version of program B. Something that developers need to avoid. The problem is not that major on OS/2 simply because OS/2 has few software most of which is very old, not because it is superior in this regard.

ad.5. The idea is that you should not want that. If you do, it means that the packagers are too lazy to provide up-to-date versions of the dependent software and should be kicked.

Regarding your Linux experience. This is a really bad one. I have much better experience with e.g. Ubuntu. Nothing like you describe except that sometimes you have to wait indeed until a new release of the software gets into its software repositories so that you can install it. This may be improved by frequently rebuilding packages, see ad.5 above. I don't find it to be a big problem in case of OS/2 ATM because we don't have too many developers and they don't release too often. Which means that you will most likely get all the newest things in YUM once the OS/2 release of them is out.  Everything else you say about your Linux experience doesn't apply here.

What you should also worry about is that some OS/2 developers may not want to create RPM packages for their software. This is clearly not a nice thing but it can be worked around since as I said above it's relatively easy to create an RPM package for any binary distribution, no matter if it was intended for RPM or not (some limitations apply).

You state that in OS/2 you can be somebody in the middle between the "dumb user" and the "experienced admin" and this is what you like about it. I say that the complexity of the modern software vanishes this position as the amount of knowledge you need to manually install it requires you to be an admin. This is what we want to avoid with RPM. WarpIn is unable to manage this software either.
« Last Edit: 2011.08.30, 13:44:10 by dmik »

dmik

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: RPM packager
« Reply #39 on: 2011.08.30, 13:40:16 »
Pete, if you think you know the software better than its developer, then you must be a more experienced developer -) In this case, you can build it yourself and change it as you like. Or create a package manager of your liking that will do everything as you like. Or do something else a more experienced developer can do. I can't see how RPM will make your life harder in this case.

dmik

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: RPM packager
« Reply #40 on: 2011.08.30, 15:16:10 »
A few more words about the dependencies (for those who wants to understand the matter). They exist on the binary level (between EXEs and DLLs). The software manager has nothing to do with their nature. It can only reflect them or ignore them. No matter if you use WarpIn or RPM or install software manually from ZIPs, this problem exists and needs to be resolved. The difference is what each method offers you to make this task simpler and less error prone. The manual method is the most powerful but it complex and much easier to screw up. The WarpIn method is too dumb. The RPM method is somewhere in between. It's much more flexible than WarpIn (as it allows developers to better describe dependencies and have them automatically resolved) and it is less error prone than the manual way (as it minimizes the human factor).

The generic problem of the Linux software not its software installers and not its directory structure, and not even its scary command line with cryptic tools. The problem is a huge developer base and a very week level of coordination between them. As a result, releases of the dependent software are not synchronized, libraries often bring incompatible changes without thinking of the existing software and so on.

I repeat again, this infamous Linux mess does not come to OS/2 with RPM or with Unix directories. Its presence or absence solely depends on how the OS/2 developers and packagers coordinate with each other. Given that there are just a few of us, I have a hope that we will be able to coordinate well. RPM and a well defined directory structure are things that will surely help us to avoid the mess. To avoid the mess on *your* computers, for *your* pleasure in the first place.

Those of you who still shout "hands off of my PC!" are free to go the ZIP way. Those who like the WarpIn way and do not want to become expert administrators, please trust us and learn a couple of simple yum commands for the time being. Your support will make a nice GUI for it to appear much faster than your negative feedback on everything coming from the Linux world by default.


djcaetano

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: RPM packager
« Reply #41 on: 2011.08.30, 16:13:31 »

   Will WPS integration be added to RPM/YUM? AFAIR, one of the reasons behind WarpIn creation, back in the xWP days, was the need for easy support to object creation, destruction, WPS classes registration and deregistration... which an eCS installer MUST do (this function is simply a mess and not functional under Linux due to zillions of different user interfaces and desktop configurations).

   In my POV, the directory tree for Linux is a big organized mess... that is: it must be that way to cope with multiusers and several other details available on Linux FSs, which are not available on eCS (such as refined security with a ruthless FS security control and the need to add directories "on the fly" via mount command).

   I do agree, though, that porting any Unix software and make it work with OS/2 directory tree is quite a challenge sometimes... so I kind of can cope with that messy directory tree structure in order to ease the Linux ports... but the directory tree can be greatly simplified. There is absolutely no need to cope with dozens of "usr" or "bin" directories under OS/2. Maybe it would be interesting to have a single /root directory with a simplified Unix directory tree inside of it, and ported software could just be installed there. In fact, this would really solve a messy situation we have right now: many ported programs store data on different directories (/ecs/dll, /os2/dll, /mptn/etc, /%home%/%user%/appname and so on).
Remember, however, that many tasks that can be done easily on Linux (such as creating a directory symbolic link named "FireFox" for a cryptic "/usr/bin/Firefox.6.0.11.beta.whatever.I.like.long.dotted.names/" to ease the access) are not available under OS/2 (which makes VERY annoying the ever changing directory names for ported applications directories, such as FireFox).

   On the other hand, I believe this should be limited to *ported* software. eCS and OS/2 native software should keep things as they have been for "centuries" now. I liked the fact eCS comes with a predefined "home" and "programs" directory. This could be extended to "Libraries" (for Shared Libraries). The programs directory is expected to have subdirectories for each program, wich will include the exe file, specific libraries, and configuration.

   From a development point of view, since RPM/YUM is so flexible, this must not be difficult and/or impossible.
   Also, I would be nice if the RPM/YUM interface could be similar to that on WarpIn and work in a similar way.

   Regards,

   Daniel Caetano
   daniel@caetano.eng.br

PS: eCS directory tree is a mess just because a different but equally hell-like directory structure was started, replicating OS2 directory with ECS name to put different things in there. Also, nothing was made to change the IBM bad habit of installing all different sort of applications in the root directory... this is just as annoying as putting everything inside /usr/bin. The TCP/IP, for instance... it has its own directory tree, on root, but it stores its configuration on /MPTN/ETC! We also have different versions of IBMGSK, the related LAN software divided into dozens of directories (IBMLAN, IBMCOM, IBMLANLK, MUGLIB...).


Pete

  • Hero Member
  • *****
  • Posts: 865
    • View Profile
Re: RPM packager
« Reply #42 on: 2011.08.30, 16:50:33 »
Hi dmik

Pete, if you think you know the software better than its developer, then you must be a more experienced developer -) In this case, you can build it yourself and change it as you like. Or create a package manager of your liking that will do everything as you like. Or do something else a more experienced developer can do. I can't see how RPM will make your life harder in this case.


I'm not claiming to "know the software better than its developer" - simply that I know my system better than the developer an d that is the way I would want to keep it  :-)


Regards

Pete

diver

  • Full Member
  • ***
  • Posts: 153
    • View Profile
Re: RPM packager
« Reply #43 on: 2011.08.30, 17:24:39 »
Peter

exactly for such cases we also deliver the ZIP's. And also a RPM can be unpacked and installed from there.
And if you know what you do, it's possible to deal with such tasks.

regards
Silvan

dmik

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: RPM packager
« Reply #44 on: 2011.08.30, 18:43:44 »
djcaetano, WPS integration is already there and it's already more powerful that the one of WarpIn. E.g. it provides reference counting for objects which e.g. means that two packages may create the same WPS folder and if one of them is later uninstalled, the folder will not go away (until the second one is also uninstalled). Class registration is not yet there (because there is no current demand in it) but it is easy to add when needed.

Regarding the Unix directory tree, I suggest you to read about FHS: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard (and the original at http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html) to have better understanding of what it is. There is a lot of good points in there, very few of which are related to the multi-user mode. it is an attempt to structure files in order to clean up the mess (not to create it).

You suggest that there should be a single Unix-like directory tree for all applications, but that is exactly what RPM does (this tree is pointed to by the UNIXROOT environment variable). We also have symlink support in all LIBC-based applications and for others it's just a question of rebuilding them with GCC in order to get symlinks there. You cannot obviously rebuild WPS, but you can subclass it and bring support for symlinks there as well, if/when really needed.

You mention that the native OS/2 directory structure is a mess too. I fully agree. One point of  RPMizing eCS itself is to clean up this mess as well. There are a few directories that can't be easily cleaned up (IBMLAN for instance), but that's not a big deal to keep them as they are until they get replaced by modern components (e.g. the whole IBMLAN thing is not actually necessary since we have Samba nowadays). Regarding the exact directory names like "Programs" see my reply to miturbide, it also explains why having the Mac-like approach you suggest (a separate directory per each application) is not suitable.

Regarding the YUM/RPM interface, it's not clear if you mean the GUI or the command line or may be the packaging interface, so I can't comment on that.

Pete, by the "system" you probably mean that you better know what you want the computer to do for you. No doubt on that. While many years ago it would also mean that you better know how it should do that, this is no longer true. "What you want" is still your privilege, but "how you will get it" is not -- unless you are a system administrator (or a developer, or just a very curious user with a lot of free time), of course. I have a feeling that this is what most people fail to understand.
« Last Edit: 2011.08.30, 19:06:50 by dmik »