OS2World OLD-STATIC-BACKUP Forum

OS/2 - Technical => Setup & Installation => Topic started by: minou on 2011.08.28, 07:35:09

Poll
Question: Do you want an RPM/YUM implementation for OS/2 that uses the Unix/Linux "Filesystem Hierarchy Standard" (/home, /var, /usr, /etc..)?
Option 1: Yes votes: 14
Option 2: No votes: 18
Option 3: I don't know votes: 2
Title: RPM packager
Post by: minou on 2011.08.28, 07:35:09
A few months ago several people show a lot of anger toward the shift to rpm packager and yum. I was quite surprised to the reaction because this very fact is the reason that I am spending the money to buy eComStation. You have to understand that the only way that OS/2 will survive is to have more developers and more applications. At the time that IBM dumped OS/2 and gave us the finger I considered myself a proud member of Team OS/2 USA. It soon became impossible to have system at a decent price that was stable. Linux quickly became my preferred system, somehow I could never accept to switch to windows at home even though this is what I have to use at work.
When I learned that eComStation was using yum and rpm I didn't hesitate to get the money necessary to paypal so wednesday I should be getting my copy of eComStation 2.1.
I have been creating packages under slackware, redhat rpm packages (as well as SuSE, Centos, Scientific Linux and Mandriva), gentoo packages and ubuntu (debian) packages for many years.
The easiest ones to create are the rpm and gentoo packages. The advantage of gentoo is that it can use packages from everybody but it is a lot more complicated than rpm. The ones who are a real pain are the debian packages. The parser barfs when you put tabs in the scripts. When I first started to create packages for ubuntu it took me hours to figure out that all the errors messages were bogus and related to the fact that the parser didn't like tabs. Using joe or vi editors were the solution as files edited with gedit would make the parser of the debian packager generate tons of error messages. rpm packages are very easy to create and very portable. Some sites have their own scripts to annoy us but once you get their macros you're ok. All that is needed to learn how to use rpm is the good old RTFM.
Watch in the next few months for ports of gcc for the PIC 32 and AVR32 as well as the debuggers for those.
I intend to get setedit to work with ARM, PIC32 and AVR32 boards on OS/2. Kate is also on my list when QT4.7 will be available for OS/2. They will be in RPM packages of course.

There is a good reason for the structure used in Linux, FreeBSD, the MAC or unix, it is so you can have a more stable system without crashes because of conflicting files. A good packager like RPM which has been proven over the years greatly help. Why recreate something that is working very well? they could have picked different ones but rpm is actually the best in the industry. urpmi or yum are popular tools that make rpm easier for those who are not familiar or do not want to familiarize themselves with rpm. If you want to give applications to install on a jump drive it is very simple as you can create a repository on any disk directory.
All the complaints I have seen on rpm were people who most likely shouldn't be allowed anywhere near a computer.
If you install rpm packages with the "--no deps" argument, do not complain for messed up data base. rpm packagers warns you that stuff is missing and if you insist it will let you screw things up with "--no deps" because sometimes you do have the files installed directly but if you do this without those files don't blame rpm for trusting your good judgement.

If you really dislike it just use unrpm and do as you please. Personnally I see the change as a brillant move that could help OS/2 get back to life. What we need now is more people willing to spend some time porting stuff. Having a similar structure as on Linux will greatly help. If you are not sure about this just check mingw. We could eventually even create binaries for OS/2 that can be created under Linux or MAC. An OS is dead without applications and there are a lot of good applications on Linux that are just waiting for people wanting to port them.
Title: Re: RPM packager
Post by: melf on 2011.08.28, 17:00:07
The answer is quite easy for me. Such a basic and important program as an installer must behave like an eCS installer on an eCS system. I as an eCS users don't use the system because I like the *nix systems. I don't want a directory structure that is like *nix. I want to decide where my programs will install without the need to turn to some "advanced mode". I want a transparent system that I can manage and control although I'm not a programmer (or a "person that shouldn't come near a computer").

This means no objections to use ported *nix programs but a very decent demand to make programs that as very far as possible behave as I expected an eCS-program to work.

One can surely learn from other systems, but you have adapt to and to stay with the basic standard people are used to and like.
Title: Re: RPM packager
Post by: DougB on 2011.08.28, 19:39:17
My view is that I don't like the way that RPM/YUM tries to take over my system. For many years, I have been able to isolate each program from the rest, and I object to having to accept somebody else's idea about how to set up my system. That is also one of the major objections that I have with Linux.

I have no problem with extracting programs from RPM packages, but all too many of them won't run unless they are installed in the very restrictive way that RPM/YUM wants to install them. FWIW, I will not bother to use a program that cannot be installed where I want to put it, in the way that I want to install it. I have never been very impressed with most Linux programs anyway. They tend to have far too many command line parameters (mostly useless), and trying to actually figure out what those parameters actually do (so I can select the 2 or 3 that actually do something useful), takes a lot of work. Most of the time, if I can't find something that works, in about 5 minutes, the program is filed in the trash, and I won't bother with it. There is no excuse for that sort of BS these days. My view is that if you want to use Linux programs, use a Linux system. ECS tends to work in a much different way, and is not subject to the restrictions that RPM/YUM wants to enforce. Not only that, but the RPM/YUM installation tends to make other programs not work (SAMBA is one of them), because it wants to change some basic system settings for it's own use. This is NOT acceptable.

We now have the QT support, which allows us to have a lot of programs, most of which have no special installation requirements (other than having the support package installed, and that is installed in a way that eCS normally works). We don't really need the Linux software, however, it does mean that we may be missing a few useful things. The main one is ClamAV. I have had little success with trying to use the later versions of that (now well out of date anyway), but if I try to install it using RPM/YUM, a lot of other things just quit working, and ClamAV is pretty restricted in what it will do. (No, I don't use ClamAVGUI, because it doesn't work the way that I want to use ClamAV).

I may install RPM/YUM on my old test machine (when I get around to rebuilding it), but it will never go back on my main machines, unless some major changes are made to the way that it works, to make it more user friendly.

If you like what RPM/YUM does, by all means use it, but don't be surprised if it causes grief with other eCS programs. I use eCS because I like the way that it works. I don't use Linux, because I don't like the way that it works. So, don't try to tell me that I need to change my ways just to use a few programs that I don't much like anyway.
Title: Re: RPM packager
Post by: Pete on 2011.08.28, 20:23:02
Hi minou

If you are purchasing eCS2.1 because you think it uses rpm/yum then you are going to get a surprise as it does *not*; hopefully it never will.

I'm sorry but I'm 1 of those people who "who most likely shouldn't be allowed anywhere near a computer" as I do *not* like rpm/yum. Like other responses I want to install software where I want it to go *not* where someone else thinks it should go.

If I wanted a linux installer I would be using linux not eCS.

Regards

Pete
Title: Re: RPM packager
Post by: minou on 2011.08.28, 21:16:32
yum is not understood, yum is only some wrapper for RPM. RPM is the package manager. yum just makes life easier for people not familiar with RPM. yum is not the package manager.
As for RPM, actually you can install programs anywhere you please, even without using the program manager. The problem when you do is that when you install a RPM package that needs a library that has not been installed with the RPM manager, you need to override this with --deps. I do that often on gentoo because sometimes the program will not compile with the gentoo packaging, gentoo is more restrictive with all these use flags. It makes a system more robust but hard to add stuff that is considered "unstable". On OS/2 you can do pretty much the same. I found warpin not appropriate for I like to do and RPM more robust if done correctly. My point is that it is ridiculous to go beserk because someone decided that RPM was very good and superior to warpin, a decision which I actually agree with.
When you make a mix of different packaging ways you risk having issues, yum or RPM for that matter doesn't force you to put stuff where you don't want to. All RPM does is keep track of what is installed and what is not installed. If you wanted you could have different places to install stuff, all very well supported by the spec files. You just have to do a few overrides. All that is needed is to make sure that the path is updated. Having binaries in a structured way makes it easier to maintain a system, that is why most server maintainers will always prefer some sort of UNIX platform.
This doesn't mean that you are restricted to that. The one who forces installation in certain places is not yum or RPM but whoever builds the package.
If the command line is a problem for people there is a way around that. yumex or some other program could easily be ported to OS/2.
I am not buying eComStation because of the RPM packaging use but that helped me make the decision. I have been doing embedded design and programming since the mid 70s and really disliked having to switch to windows. I had no problem with CPM, DOS and OS/2 and even windows 3.1 but with Win 95 and up and Microsoft destroying OS/2 that took the cake.
Lately the gnome group has decided to destroy our good gnome with their gnome 3.0 crap, that didn't go very well with me considering that I find KDE such a bloat that I can't stand how slow it is compare to my good old gnome 2.xx
My alternative is OS/2 or create my own fork of gnome.
I have tried going back to OS/2 4.52 but too many things just don't work as nicely as on my Linux installations (gentoo, fedora 15, SuSE 11.3, Centos and Scientific Linux). I have a lot of code on Linux which I want to port to OS/2. I do mostly embedded programming (AVR32, PIC32, ARM) and had been stuck with windows until both Atmel and Microchip came out with some support for Linux. I think that the support for AVR8 and AVR32 should be easily portable to OS/2. For the PIC32 it will probably will take a bit more work.
eComStation 2.1 with tons of bug fixed and support for RPM will make my life a lot easier. If any of you do that kind of development and have some ideas how you would prefer the directories setup for that project just let me know.
Things don't have to be installed on /usr,  /usr/local or /opt.
Title: Re: RPM packager
Post by: aschn on 2011.08.29, 00:31:51
Quote from: DougB on 2011.08.28, 19:39:17
My view is that I don't like the way that RPM/YUM tries to take over
my system. For many years, I have been able to isolate each program
from the rest, and I object to having to accept somebody else's idea
about how to set up my system. That is also one of the major
objections that I have with Linux.

OK - apparently you talk about the File and Directory Standard (FDS).

RPM/YUM is a set of installation tools - it doesn't define a FDS. IMO,
the discussion about RPM/YUM exposures a problem the actual eCS
installation has: The outdated IBM OS/2 structure is a standard and
changing or extending it has to be well-considered and adapted
continuously to our needs.

The current additional eCS tree is a mess. No, I don't want an
additional Unix tree either - unless it's well-considered. (I already
have several of them, each larger project that deals with Unix-ported
stuff has its own.)

For me, the ClamAV example you give and what you're worrying about
doesn't have much to do with RPM/YUM. IMO, it installs a common
Unix-type file structure, because developers decided that it would
ease other and future steps.

It looks to me the first time that Dmitry and Yuri don't restrain it
on their own projects only, but on the entire eCS structure for the
future.

I really see RPM/YUM and the discussion about it as a chance to clean
up our (nearly undefined, but existing) FDS. For Unix-ported stuff, we
can't avoid an additional Unix-style FDS, but to limit that to one
additional Unix FDS would ease much for everyone.

--
Andreas Schnellbacher
Title: Re: RPM packager
Post by: Pete on 2011.08.29, 01:51:57
Hi Andreas

I thought eCS had an FDS defined? - eCS File and Directory Standard (eFDS) http://en.ecomstation.ru/showarticle.php?id=92

I would think it is possible to make *nix  ports follow the above FDS; might make a bit of .extra work for the porter though...

Regards

Pete




Title: Re: RPM packager
Post by: Paul Smedley on 2011.08.29, 12:19:30
Hi Pete,

Quote from: Pete on 2011.08.29, 01:51:57
I would think it is possible to make *nix  ports follow the above FDS; might make a bit of .extra work for the porter though...

Of course it is possible, but the amount of work varies from quite a bit, to a whole heap depending on the app...
Title: Re: RPM packager
Post by: CDRWSel on 2011.08.29, 15:17:47
RPM/YUM is not good for end user. May be it could have some interest on a server.
How to have multiple unixroot defined under a same config.sys ?

>:(

cheers

Title: Re: RPM packager
Post by: lewhoo on 2011.08.29, 15:19:42
What I fear about OS/2 port of RPM is the "easy road". Currently most of OS/2 installers allow setting destination path in an easy, GUI way. No command line switches, no configuration files editing. I fear that this will not be priority in the port and, because of lack of the programers, it will not be there for a long time. Thus because of this significant part of users may start to install in default, messy UNIX like locations and those locations will slowly become default. This is the worst scenario possible for all people preferring OS/2 over linux.

Of course, it was mentioned that there are gui tools interacting with rpms which could simplify the installation procedure and choosing target path. However, external gui tools interfering with command line tools is one of the most important reasons for me not to think of linux as a really GUI-centred, end-user oriented system. It is not that rare that the gui tool is no more fully compatible with the command line tool (or was not from the beginning). If there are to be two layers of rpm for OS/2 - command line and GUI, I would be calm only if they were developed by the same team in the same time with similar final-result priority...
Title: Re: RPM packager
Post by: DougB on 2011.08.29, 18:37:46
QuoteHow to have multiple unixroot defined under a same config.sys ?

It can be done, to a limited extent, using a wrapper, or the facility in Dragtext. It may also be possible using RUN! (but I haven't tried that, yet). Of course, all of those are work arounds, that should not be necessary. The biggest problem is that you may need to use a different LibPath, and Begin/EndLibPath don't always work properly.
Title: Re: RPM packager
Post by: Fahrvenugen on 2011.08.29, 18:46:47
Forgive me if I'm missing something, but I thought it had been pretty much established that the current preferred installer for eCS is Warpin.

Title: Re: RPM packager
Post by: dmik on 2011.08.29, 19:21:27
Hello, thanks to minou for starting this discussion.

I want to make some clarifications.

What I see here (and everywhere else regarding this topic) is misunderstanding of the concepts. Despite everybody wants to think so, this problem has nothing to do with the religion. The whole question may be split up in two parts.

1. Reasons why developers want RPM.
2. Reasons why old-school users don't want RPM.

WHY DEVELOPERS WANT RPM

Ten years ago software was much simpler. A typical application would have one .EXE file and may be a couple of support .DLLs which often were pieces of external software this application depends upon. Other dependencies would include OS and Compiler runtime DLLs that were part of the OS itself and therefore were always installed on the user's computer. More over, these system dependencies were rather static as the system DLLs rarely changed in an incompatible way.

Nowadays the situation is completely different. Due to the fact that software becomes more and more specific as its complexity grows, a typical application now has a score of external dependencies which are *not* part of the OS installation. These dependencies also have their own dependencies, and each file needs to be of a particular version.

Because of the dramatically increased number of external dependencies and their stricter nature, the approach of packing each dependency with the application itself does not work any longer. Putting all hard disk space constrains aside, it creates a well-known DLL hell which, even if you manage to sort it out with hacks like LIBPATHSTRICT=T, eventually beats the whole purpose of a Dynamic Link Library which is intended to share the common parts of code among applications in order to save computer memory and other resources.

Making these external dependencies part of the OS itself (this is something eCS people have been trying to do) doesn't solve the problem because if we talk about modern software then we find that it is alive and changes over time. This means it is not static (as opposed to some ancient OS/2 system DLLs) and therefore it needs to be updated too. This just creates exactly the same problem as described above.

So the only thing the developer is left with here is to list all the dependencies in a README file, carefully describe all the steps necessary to install these dependencies and pray to god that the user has enough knowledge and experience to follow them. The more complex the software and the dependency list is, the higher is a chance that the user makes a tiny mistake that will lead to a completely broken installation, which is usually followed by blaming the developer for creating "such a crappy program" (with this statement being a completely false in 95% of all cases). Everybody is disappointed. For *no* reason.

All this created high demand in a program that would manage software installation on behalf of the end user and address the question of resolving the external dependencies in the first place as well as the task of configuring the installed software to create a proper environment that is expected by the developer for his software to work in.

RPM and YUM do just that. They are chosen simply because they turned out to be easier to port them to OS/2 than other similar tools. No religion here. No OS wars. It's like a saw for cutting wood when you realize that a knife doesn't work well any more.

WHY OLD-SCHOOL USERS DON'T WANT RPM

It's pretty clear, actually. From the days when the whole OS would fit on a 3.5' floppy disk, people used to be in charge of the entire system and its environment. They want to know what files the software puts on their hard disks, they want do decide which directory these files get written to. It all made sense back then, when the resources were very limited and the software was relatively simple so that the whole OS installation was manageable by a more or less experienced end user. Such manual control would let him optimize the system to best fit his needs and get the best out of the available hardware. It was very important.

In such situation, revoking this level of fine-grained control from hands of the end users is expectedly treated by them as the infringement on their freedom. And gives them all the mental pain it may cause.

However, today, due to the reasons described above and with the increased complexity of the software in the first place, the average end user has little to no knowledge what a particular piece of software needs and how it should be installed to work as designed. Which means, responding to the common "I want to install software where I want it to go" argument, that this argument is no longer valid. The developer of the software knows it much better.

There is no offense in this. And no limit on the freedom. You are still free to choose what software you want to install. This is where your individuality shows up. Developers offer you applications, you decide which ones serve you best and credit the respective authors. All the installation details are sorted out for you by specially designed tools. No reading installation instructions, no seeking for the right version of the dependent library, no even need to download anything by hand. And no need to care about future updates. Developers develop, users use. Everybody is happy.

I will give you another example. Consider you buy a car. If you are an average driver that needs the car to go from point A to point B, you will not complain that the engine is in front and you are not allowed to move it to the trunk. It is too complex for you to manage such things on your own and you probably have other things to do in your life that are much more important than taking care of your car's engine.

The modern software is just the same thing.

Of course, there are geeks over there that would disassemble their new cars and assemble them back putting everything the way they want. But hey, if you can do that, you will for sure be able to rip RPM off even if the whole eCS will come completely RPMized one day (it will). And especially for you we (the people who do Qt/Java/Odin/Unixports/etc.) will always provide ZIPs for all software we release as RPM. Just to make your life a bit easier. For the small but expected price -- you will have to sort out all dependencies and environment settings on your own. Which implies taking the risk of screwing up your system as well as recovering from such failures.

However, you should take into account that given the aforementioned complexity, it is impossible to describe every detail of the manual installation procedure and all possible pitfalls in the README. The multiply of the dependencies and environment parameters that the user is able to change on an eCS system gives us many hundreds of possible combinations and we are physically unable test them all. Even if we had a hundred of people in the test team (recall Windows). No need to mention that actually we have no (zero) paid testers.

All in all, our sole motivation to move to RPM is to increase the overall quality of the provided software by minimizing frequent problems that arise from incorrect installations and various conflicts with other software, as well as to simplify the task of managing software for those end users that don't want to be geeks in order to use their computers with the beloved operating system. Easy installation and update mechanisms also let us provide more frequent updates without disturbing end users too much which, again, means the increased software quality.

I hope this post helps you better understand the decision to move to RPM as well as the benefits it will give you as end users. If you have reasoned questions, feel free to ask. I will try to answer.

P.S. You may ask: we already have WarpIn. Why is it not enough? The answer: WarpIn is a great tool and it was a revolution in the OS/2 world in 90s, compared to these different application-specific installers we had (especially those ones from IBM). But WarpIn has some limitations which make it not sufficient for the modern software. These are its major limitations:

  1. No way to perform an update that removes files.
  2. Weak dependency handling, e.g. no notion of conflicts or alternatives.
  3. No support to automatically download and install dependencies.
 
An attempt to add this to WarpIn is equivalent to re-writing it from scratch. We chose RPM instead of re-involving the wheel to save the resources and direct them to other useful tasks.

P.P.S. There is a section in the RPM/2 Wiki that shows you the basics of the YUM and RPM command line, http://svn.netlabs.org/rpm/wiki/RpmHowToEndUsers. Just to demonstrate you how easy it is to install software with these tools even in the absense of the GUI front-end (which is another frequently used argument against RPM). No need to say that a GUI front-end for YUM and RPM is in our roadmap and those who attended at WSE'2011 could even see an early prototype.

P.P.P.S. The File and Directory Standard is a slightly different topic and it is not strictly connected with RPM. (Though it is connected with the question of creating an easily manageable complex system for which a tool like RPM is one of the requirements and a clearly defined FDS is another one).
Title: Re: RPM packager
Post by: miturbide on 2011.08.29, 21:56:46
dmik, since I'm not a Linux users and I ignore how RPM works my question is:

Are the software installers made with RPM offers the same user experience for eComStation as WarpIn?
1) Can I install software with a simple double click and follow the GUI install procedure?

Thanks
Title: Re: RPM packager
Post by: miturbide on 2011.08.29, 22:14:03
About the "eCS File and Directory Standard (eFDS) (http://en.ecomstation.ru/showarticle.php?id=92)" I think it still remains too complex and should be simplify to:

- \eCs
- \Programs
- \Home

and thats all that it should be on the root.
(of course that is currently not possible because we have hardcoded /desktop /os2 /mmos2 ...etc)

I also dislike the Linux/Unix directory structure. It is too complex, thats why for example MacOS hides that structure from the user and presents a simpler one.
Title: Re: RPM packager
Post by: melf on 2011.08.29, 22:40:53
One problem with you rpm-guys postings here is your attitude:

minou says: "All the complaints I have seen on rpm were people who most likely shouldn't be allowed anywhere near a computer."

dmik says: "Which means, responding to the common "I want to install software where I want it to go" argument, that this argument is no longer valid. The developer of the software knows it much better."

I'm sure you know a lot about programming, but you seem to know very little about how to listen to and deal with users and to consider user's preferences.
Title: Re: RPM packager
Post by: lewhoo on 2011.08.29, 22:50:54
dmik:

You are perfectly right in your argument - saying that most users do not need such features as this "freedom" of where to install,etc. Other users,those "geeks" can still be "geeks". However, these averege users are already using Windows,MacOSX and shiny linux distributions. Those "geeks" use mostly linux.

Do you plan on exchaning many (if not most) OS/2 users that do not fit in those categories to those that fit? Well, I wish you good luck. However, I am afraid that the result will be just loosing lots of eComStation individual clients.

If you want to make the ECS as "simple" with installations as linux, than I am afraid it may be too much for me. I have to use linux every day for scientific work and quite often I have to face these "developer had much better idea where to install than user" issues. It is a mess I am into only because I have to be.

And finally - I really do not understand your attitude. You should focus on what user wants, not what is more convenient for you. Without users, ECS will not exists, no matter how happy with its future design developers are. Or maybe, as I said, you are hoping to obtain so many new users that you won't have to worry with loosing current ones. I'm affraid this possibility is rather illusory.
Title: Re: RPM packager
Post by: miturbide on 2011.08.29, 23:05:18
melf: I agree with you.
Title: Re: RPM packager
Post by: dmik on 2011.08.29, 23:34:21
melf, excuse me, but you have probably misread me. In that paragraph I was talking about the average user. It looks like you don't consider yourself as such, so you should probably refer to the section related to "geeks" in my post.

miturbide, answering your question. There is nothing to double click (yet), but you can install software with a single command line, e.g. if you want to install the latest version of Odin, you will open a Command Prompt and type:


    yum install odin


That's all. And since the installation is completely unattended (for 99% of the software), there is no "installation procedure" to follow except the above yum command. Speaking about the current state of affairs, there is nothing comparable to a single double click when it comes to installing applications on eCS (even using WarpIn, don't forget that you will have to download .WPI files + all requirements and then locate them in your Downloads folder, etc.), so YUM/RPM will be already a major improvement here.
Title: Re: RPM packager
Post by: miturbide on 2011.08.29, 23:47:24
dmik. Like always, you are free to do whatever you want.  But my main problem is that you are reducing the user experience on the software installers.

So with RPM you will have to open a command line and type to install an aplication. While Windows, MacOS and OS2 with WarpIn had installers that you can simple double click them and follow the wizard to install the software.

RPM may be technical superior to WarpIn, but the user experience in WarpIn is simple. Users don't want to loose that.
Title: Re: RPM packager
Post by: dmik on 2011.08.29, 23:50:24
lewhoo, sorry, you seem to not read me well too. I say quite the opposite -- the whole move to RPM is to deliver software of a better quality. It's the end user who benefits best of all from this move in the long run (even though not everybody understands/believes in that, but that something we expect).

Regarding your Linux experience, I didn't understand what you mean and I don't see how it relates to eCS and/or RPM. Feel free to clarify.
Title: Re: RPM packager
Post by: melf on 2011.08.29, 23:52:03
Quote from: dmik on 2011.08.29, 23:34:21
melf, excuse me, but you have probably misread me. In that paragraph I was talking about the average user. It looks like you don't consider yourself as such, so you should probably refer to the section related to "geeks" in my post.

I doesn't really matter if you referred to the me or "the average user", the attitude of "developer knows best" is still there. I miss the user perspective and the will to try to understand.
Title: Re: RPM packager
Post by: dmik on 2011.08.30, 00:15:05
miturbide, do you seriously think that

1. Download WPI.
2. Read requirements.
3. Find and download requirements.
4. Double click / unzip / whatever all requirements.
5. Double click WPI.

is simpler than

1. Open Command Prompt
2. Type yum install <package>

If your answer is "yes", then there is nothing to discuss. You just need to try it first.

melf, it is still there, but the context matters. Does the phrase "the surgeon knows it much better" when it comes to fixing a "bug" or installing a new "feature" to your body offend you too? If the answer is "yes", see above -) I think what you miss here is honoring your own longstanding habits by developers (so you care about yourself in the first place, not about other users). While no doubt that the developers should take users' habits into account, sometimes these habits become an obstacle for further improvement of the experience and this is just the case.

To all: Please be more specific when you criticize something. E.g. "I don't like A because I need B and A makes B impossible. I need B because of C". I will try to comment on that with my knowledge. I'm here not to flame with you guys (I have neither time nor will for doing that), I'm here to explain & help & collect your constructive feedback ("my attitude is longer than your attitude" is not constructive).
Title: Re: RPM packager
Post by: miturbide on 2011.08.30, 00:26:22
(dmik: I'm responding in your same terms)

Do you know what "user experience" means?

if your answer is "no", then you are right.
Title: Re: RPM packager
Post by: DougB on 2011.08.30, 00:37:49
I doubt if this will make developers happy, but I don't have time to respond to each point individually.

If a developer is not smart enough to reduce a program to the simplest user experience (including installation), their software is not going to be used by very many people. As I noted before, Linux software seems to be a contest to see which programmer can make a program that is the most difficult to use. This is great fun for the programmers, but it is not any fun for the potential user. Adding a horrendously complicated installer to the mix (no, I won't waste my time trying to type a couple of hundred characters to install a program), and you have a totally useless pile of garbage.

As noted, I do have the option of not using any of it. I fully expect to make full use of that option. ECS is not Linux, and there is no excuse for making programs that are complicated to install, and use. Very few of the current crop of ported Linux programs are usable as it is, so I can't see that they will get any better by using a fancy installer that makes more work than it eliminates (for the user). True, it may cut down a little on the porters work, but is it really worth it when it destroys one of the best parts of eCS? Personally, I doubt it.
Title: Re: RPM packager
Post by: dmik on 2011.08.30, 01:03:07
miturbide, my answer is yes, I know what it is. This doesn't make it clear what is your answer to my question though.

DougB, you are right. I second your words completely. The whole RPM thing is about "reducing a program to the simplest user experience (including installation)". Interesting to note that if I express the very same thing with different words ("the developer knows much better"), I face hates from the very same people which experience you think this should simplify -) May be you should first decide who do you think the majority of the OS/2 users are: geeks, average users or blonde girls. My opinion is that the average OS/2 user has basic knowledge of the command line.

The RPM interface doesn't have a shining UI yet (like e.g. the one in Apple's AppStore) but what you already get is very close to it and much simpler than anything that OS/2 users have been having until now. Yes, you have to type, but not hundreds of characters, of course. Just three simple words in most cases.

I agree that creating a nice UI for the installer first (and thus hiding the RPM/YUM details from you completely) would be more user-friendly, but the thing is that we need a new software manager tool right now. Otherwise we would have to hold all our releases or provide them as ZIP only (which is much more difficult to manage than yum install <pkg>, you must admit). For example, it is simply impossible to use WarpIn to create a proper installer for the upcoming Qt 4.7 release.

And one more important note. Yes, having RPM in action will indeed make these ported Linux programs you mention more usable, that's one of the main points. If you want details, I can explain why.

Your argument about the amount of work for developers is a pure speculation: according to your own words, you don't know what RPM is and therefore you cannot know if it will cut down their work or increase it.
Title: Re: RPM packager
Post by: miturbide on 2011.08.30, 01:24:16
dmik you don't seem to understand why the people complains about RPM on the forum.

Once you have a nice installer like WarpIn, nobody wants to go back to use the command line (no matter if it is easy as "yum install odin"). No matter if it grabs all the requirements and installs it for your. 

Also, my first RPM experience (the one that was inside an WarpIn installer) was terrible.
Loot at the RPM-YUM documentation for the end user: http://svn.netlabs.org/rpm/wiki/RpmHowToEndUsers
Do you think it is easy and looks nice for the end user?

RPM/YUM may be powerful and fine for the backend, but you need to show an frontend with a GUI that will make it easy for the user to install and un-install, to select packages, etc. 

But maybe I also need to test RPM further, which installer are working right now with RPM and YUM? I will give it a try.
Title: Re: RPM packager
Post by: dmik on 2011.08.30, 01:47:49
miturbide, of course, I understand your argument about WarpIn vs command line very well. More over, this is the reason why I am here on this forum. I know what people think about it and I want to explain that you should not fear RPM. It is easier than it looks like. Except for the "scaring" command line, it is even easier than WarpIn.

I understand that your first RPM experience was terrible. Believe or not, but so was mine -) But hey, nobody is perfect at first shot. We've been constantly improving the OS/2 reincarnation of RPM and related stuff. It's quite acceptable now.

Regarding the HowTo page. This starts to resemble the useful talk, finally -) What part of it do you mean in particular? I think that the first paragraph (Handy YUM and RPM commands) is quite simple to understand (again, I consider OS/2 users as people familiar with the command line on a basic level). The subsequent paragraphs contain too much low level details and should be moved somewhere else.

I do also have an idea of making an even more simple Wiki page that will only mention the install command and give a couple of examples. This page will also contain a very simple instruction on how to bootstrap RPM (this all will be done before we release anything in RPM). Any suggestions are welcome.

Regarding testing it further. You can only install a bunch of the Unix command line tools with it plus things like zip/clamav ATM which is probably not very interesting for you. Please wait until we release Qt4.
Title: Re: RPM packager
Post by: Pete on 2011.08.30, 03:19:06
Hi dmik

Could you clarify if you will be repackaging *all* available os/2 software so that it can be installed/updated by rpm?

If you are not then rpm simply becomes yet-another-installer-for-os/2 with a limited selection of packages to install/update.

I certainly do not agree with your "developer knows best" concept. However, I may be a "geek" - I also used to dismantle motorcycles and build "chops" from them which must be close to what you meant about users rebuilding cars to suit their ideas.

I've used rpm a few times when playing with linux systems and never enjoyed the experience. I think this is because I like to know *what* is installed and *where* on *my* system.

However, before writing off all your work I will test rpm - are there any rpm software packages to try to install yet?

Regards

Pete




Title: Re: RPM packager
Post by: Pete on 2011.08.30, 03:22:43
Hi All

This is another thread that seems to be becoming rapidly inaccessible - I cannot get page1 of this thread to appear no matter what I try.

In the hope that it will help the os2world guys debug the problem(s) this is what I currently see when I try to access page1 of this thread:-

8: Undefined offset: 0
File: /home/os2worldcom/httpd/html/components/com_smf/smf.class.php
Line: 449

Regards

Pete
Title: Re: RPM packager
Post by: miturbide on 2011.08.30, 04: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
Title: Re: RPM packager
Post by: miturbide on 2011.08.30, 04: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.
Title: Re: RPM packager
Post by: David McKenna on 2011.08.30, 05: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
Title: Re: RPM packager
Post by: abwillis on 2011.08.30, 05: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.
Title: Re: RPM packager
Post by: lewhoo on 2011.08.30, 10: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!
Title: Re: RPM packager
Post by: diver on 2011.08.30, 11: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
Title: Re: RPM packager
Post by: Pete on 2011.08.30, 14: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




Title: Re: RPM packager
Post by: Pete on 2011.08.30, 14:07:42
Hi Martin

Quote from: miturbide on 2011.08.30, 04: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


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
Title: Re: RPM packager
Post by: dmik on 2011.08.30, 14: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.
Title: Re: RPM packager
Post by: dmik on 2011.08.30, 14: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.
Title: Re: RPM packager
Post by: dmik on 2011.08.30, 16: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.

Title: Re: RPM packager
Post by: djcaetano on 2011.08.30, 17: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...).

Title: Re: RPM packager
Post by: Pete on 2011.08.30, 17:50:33
Hi dmik

Quote from: dmik on 2011.08.30, 14: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.


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
Title: Re: RPM packager
Post by: diver on 2011.08.30, 18: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
Title: Re: RPM packager
Post by: dmik on 2011.08.30, 19: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.
Title: Re: RPM packager
Post by: miturbide on 2011.08.30, 21:31:32
Quote from: dmik on 2011.08.30, 19:43:44
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).

dmik, reading about how the Unix FHS is organized it is not going to make it easier, or it is not going to make people like it. The FHS is complex and old. Maybe Unix users will like to know how the system is organized. But OS/2 is not a Unix, implementing the same FHS in OS/2-eCS is a bad idea. That's my point of view, and many other think it the same way.

Is it obvious that "/etc/" are the "Host-specific system-wide configuration files"? It is old, it is not user friendly.
Title: Re: RPM packager
Post by: dmik on 2011.08.30, 22:01:20
miturbide, you are trying to sit on both chairs. Either you care about the system internals or not. There is no middle. You enter the "developer zone" by trying to discuss system internals, but when it comes to presenting arguments protecting your position you behave like an "average user" since all you can say is "I don't like it / I'm not used to it". This leads our conversation nowhere...

FHS is much less complex than the current OS/2 mess. And it is younger than this OS/2 mess -)

For whom the purpose of "/etc" should be obvious? For me it is. For you, if you are a developer or an advanced user, it will also become obvious after you read FHS. If you are not interested in this level of detail, you don't care about "/etc".

Let's for a second assume that we call it like you want, e.g. "HostSettings". What's next? While the purpose of this directory will become more obvious for you, it will still remain cryptic for my girlfriend, and it will not actually give you any idea on how exactly different applications are going to use it -- you will still have to read their documentation or source code. Needless to say that it will break many and many programs. It's a dead end.
Title: Re: RPM packager
Post by: miturbide on 2011.08.30, 22:21:17
I'm a technical user.. not a regular user, nor a developer. Many OS/2 users are of that kind.

dmik, when you attack me and try to provoke me, it is not going to give FHS more acceptance. Please don't do that.
Title: Re: RPM packager
Post by: dmik on 2011.08.30, 22:32:03
miturbide, you think way too much about the importance of your own person.
Title: Re: RPM packager
Post by: miturbide on 2011.08.30, 23:05:50
dmik, my opinion is as important as the rest of the people that uses this forum. I don't have the recognition, the merits or the resources to think I'm more important than anybody else here.

You are the one that is trying to get feedback on this forum why there are several users that don't like the idea of using RPM in the software you develop. People here are not ignorant, by sending them to read what FHS means are not going to convince them.

Title: Re: RPM packager
Post by: DougB on 2011.08.30, 23:32:13
Quotemiturbide, you think way too much about the importance of your own person.

Now there is a classic case of Pot, Kettle, Black. Dmik, I could say the exact same thing about you.

IMO, the OS/2 boot drive is a bit of a mess, but only because those who started adding things made it so. It does make a lot of sense to distribute the folders as they have been done, although a couple of them have been overused. It is, in fact, not all that different from what Linux puts into the /usr  folder. To add a whole new folder, that is just as bad, or worse, is not the answer to the problem (a minimal problem, until the linux junk gets added, then it becomes much worse). One of the BIG problems today, is the %ETC% folder. It is being used for too many things, and it collects a lot of junk. Junk that should be contained in the program folder. Now that the eCS installer has been fixed to allow the HOME and PROGRAMS folders to be located outside of the boot drive, eCS is beginning to get cleaned up. I still object to the concept of the HOME folder which also collects large amounts of junk that should be contained inside the using program's own folder. The worst part about the HOME folder, is that uninstalling programs does not clean it out, and the junk sits there forever, unless the user realizes that it needs to be removed. Then, it is a real problem to try to sort out what should go, and what should stay. More than once, I just erased the whole thing, and let programs put back what they seem to think they need. The idea of another whole mess like that really turns me off. When a program is contained, entirely, in one folder, one can get rid of everything at one go. You also know where to look when there is a problem. The mess that needs to be cleaned up, are the programs that seem to think they need a complicated setup to make them work. At most, a program should need a folder for the program, and a folder for the data. Nothing else should be required. Years ago, when disk space was somewhat limited, it did make sense to share DLLs, but that is no longer the case, and programmers should seriously be looking at getting rid of them, where possible, and incorporate the code directly into their programs. If that ever happened, about 80% of the compatibility problems would go away, along with the need to try to figure out how to use different levels of DLL for different programs. That would also eliminate the imaginary problem where a user needs to open a WarpIn installer, to determine the requirements (that is rarely needed anyway), and then go and download whatever is needed, before doing the actual install.

I could go on about this, but I have other things to do. Rest assured, that your idea of how my system should be set up, is no more valid that anybody else's ideas, and the Linux method is not nearly as flexible as the OS/2 method, so I see no reason to limit what the OS/2 user can do, just because you (or anybody else) thinks that we need to turn OS/2 into Linux. It isn't worth the hassles, and it is certainly no better. The only winner, is the programmer who decides to port some (poorly written, IMO) software so that it will run in OS/2. Everybody else loses.
Title: Re: RPM packager
Post by: Paul Smedley on 2011.08.31, 00:04:06
Quote from: DougB on 2011.08.30, 23:32:13
I could go on about this, but I have other things to do. Rest assured, that your idea of how my system should be set up, is no more valid that anybody else's ideas, and the Linux method is not nearly as flexible as the OS/2 method, so I see no reason to limit what the OS/2 user can do, just because you (or anybody else) thinks that we need to turn OS/2 into Linux. It isn't worth the hassles, and it is certainly no better. The only winner, is the programmer who decides to port some (poorly written, IMO) software so that it will run in OS/2. Everybody else loses.

Sounds like I should stop porting linux junk to OS/2 then...
Title: Re: RPM packager
Post by: miturbide on 2011.08.31, 00:26:15
Paul, your work is appreciated.
I think that it is ok to port open source Linux software to OS/2.  It is legal and it works.

But there is a difference between porting Linux software to OS/2, and trying to convert OS/2 into Linux (like wanting to use the same file system structure), which is the polemic component of this forum thread.

Even when I dream about having a full OS/2 open source clone, it does not mean to transform OS2 into a Linux distro.

Title: Re: RPM packager
Post by: Pete on 2011.08.31, 00:29:45
Hi Paul

Your choice - but do carry on porting the useful stuff, Please  :-)

Regards

Pete
Title: Re: RPM packager
Post by: dmik on 2011.08.31, 01:26:06
miturbide, what I mean that I have no interest in provoking you personally. What about your opinion, I already mentioned that I understood it. But since you don't answer questions that I ask you, and also have a predisposition against everything from the Linux world, I don't see how we can continue the discussion.

DougB, I didn't give you a reason to say that about me as I don't put myself in the center of the world. First, I have an honor to express a collaborative opinion of a group of currently active OS/2 developers *and* users (which have been discussing this topic for a long time), not only my own. Second, I'm a developer only when it comes to Qt/Odin/Java. When it comes to e.g. Firefox, I'm just a regular user, like you. And I admit that developers of Firefox have much better understanding on what environment it should have and where it should live, than me. I don't want to know what files the Firefox package contains, I only want it to browse HTML pages for me and not crash. As long as I'm not involved in manually installing or configuring it, I completely don't care about its files and directories.

The rest of your speech contains too much arrogant "junk" which makes it pointless to comment on it and describe you the points where your assumptions are wrong (you will unlikely hear it anyway). Sorry.
Title: Re: RPM packager
Post by: Pete on 2011.08.31, 04:12:07
Hi dmik

Is there an installer version of Firefox for OS/2 somewhere? - and I mean a reasonably recent build.

I don't think there is. Therefore you have to manually install it and also configure it.

Probably not your best choice as an example of software that is automatically installed and configured  :-)


Regards

Pete


Title: Re: RPM packager
Post by: Pete on 2011.08.31, 04:17:50
Hi dmik

I've just downloaded and installed http://rpm.netlabs.org/bootstrap/rpm-yum-bootstrap-1_3.wpi

Here is a silly question: I have the following in my config.sys file:-

REM [ Temporary Directories ]
SET TMP=J:\temp
SET TEMP=J:\temp
SET TMPDIR=J:\temp

So why does this package create a \tmp directory?

Why does it not use the predefined %TMP%?


Regards

Pete

Title: Re: RPM packager
Post by: dmik on 2011.08.31, 13:34:23
Pete, Regarding Firefox. This was a hypothetical example -) I don't know about any Firefox installers for OS/2. But it is easy to create with RPM and it is in the plan too.

Regarding the temporary directory. Actually it may make sense to use %TMP% indeed, all access to "/tmp" from LIBC-based apps is redirected there anyway. I will point Yuri to it.
Title: Re: RPM packager
Post by: miturbide on 2011.08.31, 14:59:35
dmik, I personally don't have any negative predisposition against everything from the Linux world, like you said...please don't put the wrong words in my mouth.

I had used it and I had taken my personal conclusions. I had good points and bad points. It is good and ok to port Linux software to OS/2, but one of the negative points I consider about Linux is the FHS. I don't consider it good idea to replica that structure to OS/2-eCS.
Title: Re: RPM packager
Post by: Paul Smedley on 2011.08.31, 15:43:40
Quote from: dmik on 2011.08.31, 13:34:23
Regarding the temporary directory. Actually it may make sense to use %TMP% indeed, all access to "/tmp" from LIBC-based apps is redirected there anyway. I will point Yuri to it.

afaik access to /tmp is only redirected to %TMP% on eCS 1.2 or later where Bart's path rewriter app was included....
Title: Re: RPM packager
Post by: djcaetano on 2011.08.31, 17:19:23
dmik,

Please, do not see this message as a challenge. I am not trying to prove you wrong or that I am right.
I am just trying to describe to you WHY some people rejects FHS... something that - at least in my case - has nothing to do with fear.

I apologize if my comments seemed obtuse, but I have a pretty good deal of knowledge over FHS. I have been using Debian distros (which follow almost strictly the FHS) for several years and I did not wanted to say "the only thing FHS has support is multi-user"... What I tried to say is "the only *good* reason to explain FHS is multi-user and security". Of course, that reflects my Point of View. On my PoV, all other "good things" obtained by FHS are simply a matter of standard... of course standards have benefits, but lets face it: not even Linux users agree when an /opt directory is needed or not! :)
(why the hell OpenOffice is/was installed inside /opt !?)

The reason for /bin, /sbin, /usr/bin, for instance, is pretty unclear, since a description like "/bin : Essential user command binaries (for use by all users)" is just pretty subjective and may be interpreted in a million of ways. What is an essential command to me may not be an essential command for you. /sbin is even more unclear... "/sbin : System binaries" What is a "system binary"? Executables provided which eCS? All of them? Should xWorkplace be placed there? Or only pmformat? A "system utility" created by an "user" should be placed there ... or only those that come with the system?
This is a lot unclear even for experienced Unix users - each sysadmin defines its own rules to decide... but in the end of the day, usually every command related to the filesystem and security goes to /sbin, everything installed by the sysadmin (small utils) goes to /bin and everything else goes to /usr/bin... what is this? An attempt to put some order in the complete mess that one finds *inside* these directories? (worst than bin is the share... why the hell someone needs a directory do place sgml files? Is really needed to place ALL help files in the same directory man? (specially when their names are cryptic and there is a multitude of them for each application)... is really this the easiest way or this was just decided to allow easier searches using grep? Is really interesting adding a "/usr/share/misc : Miscellaneous architecture-independent data" directory?
I know that using "etc", "home" and "tmp" are great ideas (they are even present on nowadays eCS systems) but this do no good if not all programmers use them (via %HOME%, %ETC% and %TMP% - I am somewhat against hard-coded path names).

But hey, it gets worst! We have drive letters on OS/2. That means repeated FHS on each drive, if everything is organized this way... at least if we continue to use OS/2 the way we have always had.

I understand the reasons to use the FHS (a simplified one, for God´s sake). I even have mine on my eCS: /bin, /lib, /tmp and /var ! Small utilities and shared libraries are always placed this way. I also understand that many Unix programs have hard-coded path names and would benefit from this structure. I also have no complains that some programmers should choose to program using this file structure.
My only complain is the "all your filesystem are belong to us" approach, which is being interpreted in the following way: "if you want an installer, you´ll have to live with FHS; if you want organize your filesystem, get the ZIP... so long, and thanks for all the fish".

You have said something that made me feel uneasy: you said there are two options... the user must know what happens inside its file system (in detail) or the user do not need to know anything. This bothered me because I have always thought in OS/2 and eCS as the middle path: it is not so dumb and limited as Windows... nor complex and "powerful" as Unix.
Basically, in my PoV, OS/2 removes all things you can configure with Linux (but you never will), but keeps the system several hundreds of times more flexible than Windows. It allows one to begin working without knowing nothing (like Windows), but has a light learning curve, allowing the user discover the system internals while he is using it (without the need to read all the how-tos). This is the opposite of Linux, where you should know the reason of every bit being at /etc/init.d just to change the damn %PATH%!

Force FHS (in opposite "of allow FHS") on eCS is perceived by me as a step towards Unix complexity... the opposite direction took by Apple with OSX - which indeed implements FHS, but hides it from the user in every possible way. Do not take me wrong: I believe the path took by Apple is even worse, I do not like my system fooling me around.

I have no problem with complexity. But I have no time to it either - and I do like to know where my printer files are, so I can adjust them when the printer fails... without the need for an internet connection and spending hours reading every single how-to ever published.

My kindest regards,
Daniel Caetano
danile@caetano.eng.br
Title: Re: RPM packager
Post by: miturbide on 2011.08.31, 17:48:27
Here are some examples on how the File System Hierarchy structure looks in three well known OSes on the market.

Linux 11.04
This is how the Filesystem Hierarchy Standard looks to the regular users.
My comments about it had been already shared in this thread.
(http://www.os2world.com/forum/index.php?action=dlattach;topic=3701.0;attach=1441;image%5B)

Windows 7
Windows 7 tried to fix the complexity by just having.
- User Files
- Windows OS directory
- Programs directory. (created both, one for x86 and other for x64)
Which as an idea I liked it, but the "User Files" directory start to grow into a big mess after time.
(http://www.os2world.com/forum/index.php?action=dlattach;topic=3701.0;attach=1443;image)

MacOS 10.6
MacOS X is a Unix-based OS, and had a similar Filesystem Hierarchy Standard structure, but the Apple guys had hidden all the structure from the users and show it a lot simpler.
When you open the hard disk you see:
- User Files
- Mac OS System directory
- Programs directory.
- Library (it may contain third-party items for the OS) (fonts, screensavers, extensions, documentation, desktop widgets...)
(http://www.os2world.com/forum/index.php?action=dlattach;topic=3701.0;attach=1439;image)

Title: Re: RPM packager
Post by: dmik on 2011.08.31, 19:03:46
miturbide, then I misunderstood you (regarding your predisposition). Okay then.

You say that you don't like FHS, but again, you don't explain why. "Just because" is not accepted. Please describe the exact problems that it brings you (as the technical user if you call yourself a such).

Your screen shots are nice, but they don't give me an answer to  the above question. No need to convince me that the Mac UI is the most user friendly one -- I'm an active Mac user and I completely agree with that.

However, you mention yourself that Mac has FHS inside, the graphical interface just hides it from the end users by default. But wait, we do not discuss here if and how we should hide FHS from end users! We talk about its existence per se, and this is what you are refusing to accept in case of OS/2. For unexplained reasons. (BTW, Mac also has well hidden BSD parts inside which doesn't prevent it from being the best).

Paul Smedley, you are probably right (though anything older than eCS 1.2 is not really supported due to the lack of resources). While we can check/add add this rewrite from the RPM installer, it is something to be sorted out still.  E.g. we have two "etc" dirs (one for UNIXROOT and one in MPTN) and that's not nice too. There may be conflicts, but both should be moved to a single point at least (e.g. /etc for UNIXROOT and /etc/os2legacy for %ETC%).
Title: Re: RPM packager
Post by: Pete on 2011.08.31, 19:16:21
Hi

I've checked the kLIBC Pathrewriter and it shows from /tmp to %TMP%

Does this mean I should not have got the \tmp directory created by the YUM Bootstrap installation?

Regards

Pete
Title: Re: RPM packager
Post by: Pete on 2011.08.31, 20:00:11
Hi

I've now got yum installed so would like to test it.

I notice the lack of accompanying documentation... looking at http://svn.netlabs.org/rpm/wiki/RpmHowToEndUsers I think I see how this is supposed to work.

Presumably, as I have no idea what packages are available for installation, I could use this command to list all available packages:-

yum list avaliable *

Now, where is yum?... Aha! found it in \usr\bin and used the above command.

No, that does not work, looks like it generates lots of python (.py) errors and finishes with:-

  File "/@unixroot/usr/lib/python2.6/site-packages/sqlitecachec.py", line 31, in
open_database
    con = sqlite.connect(filename)
sqlite3.OperationalError: unable to open database file


I tried without the '*':-

yum list avaliable


Same errors...


Ok... What am I doing wrong?


Regards

Pete
Title: Re: RPM packager
Post by: ydario on 2011.08.31, 20:28:32
Hi all,

just a few notes about RPM/YUM development, just to report here something that I showed at WSE Europe in Harleem (NL), and something more.

While FHS tree is actually used, probably it can be reduced. I say 'probably' because this will require testing.

The choice to point UNIXROOT to a root directory of a drive has been done to simplify initial work; pointing UNIXROOT to a subdirectory could already work, but most apps are not tested in this environment.

Installation of packages to FHS is only forced for core packages: nothing precludes using different paths or even relocatable packages for other apps.

There is already a GUI, QYum (I know, not really fancy name...), which I made using QT4 with python bridge: it can already browse a repository and start an installation.

So, in the end, while the current behaviour of RPM/YUM mostly resembles an unix environment, nothing prevents us to get it more OS/2 friendly.

While release 00 is FHS structured, we can get release 01 to be more friendly, and it will update itself (at least I hope so, release 01 is still empty, so we can't test...). And then move to 02, 03, ...

We need only one thing: more resources (read developers) to work on it.

I hope you  will understand this work could give you a lot of features, please be patient.

thanks,

Yuri
Title: Re: RPM packager
Post by: djcaetano on 2011.08.31, 21:26:34

  Hi Yuri,

Quote from: ydario on 2011.08.31, 20:28:32
just a few notes about RPM/YUM development, just to report here something that I showed at WSE Europe in Harleem (NL), and something more.
While FHS tree is actually used, probably it can be reduced. I say 'probably' because this will require testing.
The choice to point UNIXROOT to a root directory of a drive has been done to simplify initial work; pointing UNIXROOT to a subdirectory could already work, but most apps are not tested in this environment.
Installation of packages to FHS is only forced for core packages: nothing precludes using different paths or even relocatable packages for other apps.

  This is great news!

  I believe the oposition to a FHS would be reduced if it is
presented in a reduced form just like this:

sys (base os files, replacing /OS2 and /eCS)
   may include sub dirs like bin, lib and etc for system specific binaries,
   libraries and config
etc (system wide configurations, replacing /MPTN/etc and more widely used... maybe    including even CONFIG.SYS)
bin (programs, replacing /Programs)
   base dir for small apps and automatically added to PATH
   May include subdirs for each application, which may include /lib for
   non-shared libraries
lib (shared libraries, automatically aded to LIBPATH)
tmp (temporary files, already existis)
var (logs and other semi-temporary data, already exists)
home (user files, automatically loaded as %HOME% and added to DPATH)
   should include a subdir "etc" for configuration files

"usr" dir may be created on specific systems, when development applications are installed, and inside all those development directories (bin, include, and so on), which may be added to the specific path variable

I don't know if this is possible, because some Linux apps are so fond of /usr/bin for installation... but in the perfect world, we could have a FHS and, at the same time, be free from "fractal subdirectory hell" that plagues some Unix installments.

In fact, the more flexible way to do that would be defining every path to a system variable (%SYS%, %ETC%, %BIN%, %LIB%, %TMP%, %VAR%, %HOME%, %USR% and so on), but I think this is not really possible (unless the libc is "hacked" to do the trick... and even then, this may be somewhat error prone).

Quote from: ydario on 2011.08.31, 20:28:32
While release 00 is FHS structured, we can get release 01 to be more friendly, and it will update itself (at least I hope so, release 01 is still empty, so we can't test...). And then move to 02, 03, ...
We need only one thing: more resources (read developers) to work on it.
I hope you  will understand this work could give you a lot of features, please be patient.

   I understand that. And I wish you all succeed organizing the mess and making everything easy for everyone (developers and users).

  My kindest regards,

  Daniel Caetano
  daniel@caetano.eng.br
Title: Re: RPM packager
Post by: Fahrvenugen on 2011.08.31, 23:16:19
Hi,

For me, having RPM or not having RPM available on the OS/2 / eCS platform really isn't all that significant one way or the other.  In the end - RPM is just another app from Linux that can get ported.  In fact an older version has been on Hobbes for a while:

http://hobbes.nmsu.edu/h-search.php?sh=1&button=Search&key=rpm306&stype=all&sort=type_name&dir=%2F

What I see is more significant (for me, at least) is the fact that I'll need to have 1 more thing to add to eCS installs in the future to make them work.

Right now when I do a fresh install of OS/2 or eCS, I find myself setting up several different installers just to be able to install stuff.

1.  Zip / Unzip (this is more then an installer, as I use it almost every day)
2.  The original IBM installer - for those older apps which use it but don't always seem to end up having all the needed DLL's to make it work (such as Embellish, the old Netscape 4.6.1, which leads to...)
3.  Feature Install (which is why I installed Netscape 4.6.1 ion the first place - I have a  few things built on FI based installs that I often install)
4.  WarpIn (for all the WarpIn stuff, obviously)

With this talk, it looks like I'm also going to need to add RPM / YUM on to this list.

As for the discussion about wanting to have control over what gets installed where and knowing exactly what is installed - I definitely am the type of user who wants this level of control.  I want to know exactly what is happening with a software install.  For this reason, my preferred installer is plain old ZIP and a text file containing info on what is needed.  This I find gives me the highest level of control. 



Title: Re: RPM packager
Post by: Paul Smedley on 2011.08.31, 23:58:28
Quote from: Pete on 2011.08.31, 19:16:21
I've checked the kLIBC Pathrewriter and it shows from /tmp to %TMP%

Does this mean I should not have got the \tmp directory created by the YUM Bootstrap installation?

No, but it means you can (probably) safely remove the /tmp directory as it shouldn't get used due to the pathrewriter rewriting it to %TMP%
Title: Re: RPM packager
Post by: DougB on 2011.09.01, 00:12:34
QuoteWhile FHS tree is actually used, probably it can be reduced. I say 'probably' because this will require testing

I expect that you will have little trouble removing a good chunk of it...

QuoteThe choice to point UNIXROOT to a root directory of a drive has been done to simplify initial work

One of the MAJOR problems, that I had, was that UNIXROOT is used by other things. When RPM hijacks that, some other things just quit working. At least change the name to prevent interference with other things. Perhaps ROOTUNIX would work.

Quotenothing prevents us to get it more OS/2 friendly.

When, and if, this is accomplished, I may change my mind about RPM/YUM. Meanwhile, it is not acceptable as it is.

QuoteWe need only one thing: more resources (read developers) to work on it.

You, and everybody else, need more developers.

QuoteI hope you  will understand this work could give you a lot of features, please be patient.

Patience is one of the things that an OS/2 (eCS) user needs in abundance.

One thing that I need to point out, is that ClamAV is far more important to the continuation of eCS, than RPM/YUM is. At the moment, ClamAV is well out of date, and it won't run without the mess that RPM installs. The last time I tried it that way, I still couldn't get ClamDScan, or ClamScan to run in the OS/2 way of associating it with a file type (*), but that was shortly after the RPM/YUM install method was first introduced. My test system is broken, at the moment, so I haven't tried too  much with the RPM thing, yet. The little that I have seen of it convinced me that I want no part of it, in it's current form. If it can be made more user friendly (and more OS/2 friendly), I will be happy to try again. Meanwhile, it seems that we are stuck without antivirus support, until you get around to fixing RPM, and update ClamAV..
Title: Re: RPM packager
Post by: dmik on 2011.09.01, 03:26:04
djcaetano, thanks for trying to be descriptive.

You say that those good things FHS gives you is a matter of standard. That is very true. This is just a standard that happened to already be here. The reasons we took it were practical:

1. We need *some* standard because what OS/2 has is not enough to keep things in order (from the software point of view).
2. We need a documented and recognized standard which matches the expectations of the open source software that is being ported to OS/2.

The FHS standard is not for users, it is for programs. Users have home folders and external/additional drives where they can organize their data the way they like; no restrictions there.

Said that, your criticism about individual directory names looses its main point. A program will understand the /etc directory even if it is named /qedw!@#&dfg. The matter here is not the name itself, but the fact that this name is consistent across user machines, across OS versions and across different programs. This is what the standard gives.

Now, I assume that you are a software developer. From that perspective, what you say about the ambiguity of some assignments in FHS is true indeed -- or was true several years ago. Now I see (I use Linux on every day basis since 2007) that things are quite stable. Most directories have clear purpose and the majority of the developers and OS vendors follow this purpose. There are still some vague areas but it doesn't actually hurt -- they are vague mostly because they are rarely used. And nobody forces us to use these vague parts of FHS on OS/2 (unless they are needed by some ported software). As Yuri said, we may decide to drop some parts later if it makes things simpler.

So, I will correct your conclusion a bit (see above about user directories): "if you want an installer, you'll have to allow the system areas of the OS to be FHS (or XYZ, doesn't really matter); if you want to organize these system areas yourself, get the ZIP". IMHO, this is pretty obvious. The program is not a human, it needs a well defined structure to be useful.

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.
Title: Re: RPM packager
Post by: dmik on 2011.09.01, 03:42:28
Fahrvenugen, RPM is capable of replacing all of them.

Pete, something went wrong during the installation. Either you made a mistake at some installation step (maybe you forgot to reboot?) or you have an environment that the RPM installer does not expect. If you do it right, "yum" is in PATH after reboot and you don't need to look for it in \usr\bin. Please check it once again. If the problem persists, I suggest you to open a ticket at http://svn.netlabs.org/rpm and provide more details about what you did (exactly) and your environment; this thread is not an appropriate place for that.
Title: Re: RPM packager
Post by: miturbide on 2011.09.01, 16:21:26
As a technical user, I prefer to know exactly where the files are located in the hard drive and try to know as much as possible of what a software installer is doing and where is putting the files. That makes it easier to try to find problems on why a program it is not working correctly, and which files do I have to copy for a backup, etc. The FHS structure will make it harder for me to understand where files are located in the hard drive.

Windows OS is not using that FHS and I haven't seen this kind of discussion with it. I guess if Microsoft will ever decide to use FHS in Windows, you will see the same kind of oposition. Apple understand that FHS is not good for usability and hides it in MacOS from the users.

It will be better to improve the File System Hierarchy standard for eComStation, that start using the same Linux FHS which is unfriendly to the final user, and will not help eComStation or OS/2 to adopt new users.
Title: Re: RPM packager
Post by: melf on 2011.09.01, 18:19:49
 I agree to that. In my view it's a bad idea to just force a layout on a system that have another tradition. It makes me feel as djcaetano said in an earlier posting "uneasy" to know that either you (as a user) need expert knowledge and  can do whatever you want - or you are regarded as someone who need to know nothing and shouldn't bother about what your system does.
Title: Re: RPM packager
Post by: dmik on 2011.09.01, 18:50:46
miturbide and all, I understand your concerns, but I repeat again that FHS is not for users and doesn't have to be friendly to them. Finding out problems in programs is not a user task. Manual software backups is not a user task either -- in fact, when all your system is RPM, you don't actually need to backup software, you only need to backup your data (which has nothing to do with FHS). If you still want to do such things, you enter a different zone; you have to learn how it is organized, whether it is hard for you or not (and having FHS documented is actually a plus here). This zone is where developers optimize things from the software PoV, not from the user's PoV. If you don't want to learn, get a program that does the job for you or hire a specialist.

FHS, RPM and the strict separation of the user and developer responsibilities don't come separately and alone, they only make sense all together. And they don't come because the developers have a lot of fun torturing users (as many of you unreasonably think here), they come because things turned out to be unmanageable otherwise. (You don't want to have the electronic injector in your car to be replaced by the mechanic carburettor just to be able to have an opportunity to clean it up on your own when your car stops in the middle of the road, do you?).

"Improving" FHS by making it incompatible with itself is clearly not better, it is worse because it will break existing software with no benefits for end users of this software (the video player will not start playing video better if you put its configuration files from /etc to /whatever).

P.S. Many of you don't seem to read what we write here. This will not help you to understand us.
Title: Re: RPM packager
Post by: Fahrvenugen on 2011.09.01, 19:48:15
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. 
Title: Re: RPM packager
Post by: dmik on 2011.09.01, 20:09:57
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.
Title: Re: RPM packager
Post by: miturbide on 2011.09.01, 20:49:23
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?
Title: Re: RPM packager
Post by: dmik on 2011.09.01, 22:10:04
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.
Title: Re: RPM packager
Post by: ivan on 2011.09.01, 22:33:34
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
Title: Re: RPM packager
Post by: miturbide on 2011.09.01, 23:34:58
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.
Title: Re: RPM packager
Post by: dmik on 2011.09.01, 23:35:58
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.
Title: Re: RPM packager
Post by: lewhoo on 2011.09.01, 23:44:11
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.
Title: Re: RPM packager
Post by: dmik on 2011.09.01, 23:48:10
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.
Title: Re: RPM packager
Post by: miturbide on 2011.09.02, 00:01:45
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)
Title: Re: RPM packager
Post by: melf on 2011.09.02, 00:21:30
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.
Title: Re: RPM packager
Post by: dmik on 2011.09.02, 00:27:33
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.
Title: Re: RPM packager
Post by: miturbide on 2011.09.02, 00:42:38
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.
Title: Re: RPM packager
Post by: djcaetano on 2011.09.02, 06:43:49
 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
Title: Re: RPM packager
Post by: dmik on 2011.09.02, 14:51:23
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.
Title: Re: RPM packager
Post by: dmik on 2011.09.02, 15:16:09
I must explicitly state that we are *not* trying to make Linux out of OS/2. We want to keep the native "weightlessness" of OS/2, the ability to work for months w/o maintenance, the possibility to unzip the boot drive onto a new hard disk and get it running, as well as the WPS concepts; all just powered up with new technologies and software.
Title: Re: RPM packager
Post by: Pete on 2011.09.02, 17:20:26
Hi

To os2world.com guys:-

I've now given up on trying to follow this and other discussions on this forum due to the difficulty of getting pages to display.

As this has been an ongoing problem for a long time now and the problem is getting worse I can only suggest that you look at reworking the website using software that actually works.

I do not expect to be able to access any response from yourselves so will "look in" from time to time to see if the problem(s) have been resolved.

Regards

Pete
Title: Re: RPM packager
Post by: Blonde Guy on 2011.09.02, 18:09:58
I tried to vote yes in the poll, but I got an error message.

I make the Suntan Special product to do maintenance on OS/2 and eCS systems. To do that, I've had to interface with all of the installers for OS/2 and eCS. I'm looking forward to adding support for RPM and YUM when I get the time. One thing that would help a lot for acceptance is to make a kind of UNIXROOT that would let people put the standard file system in a custom location. Forgive me if that is already the case.

I value having Linux ports and I believe the developers who say it's a good thing. I also value my legacy setups, all of which are supported by Suntan Special. I will have no trouble at all merging the two concepts, unless there is something in RPM/YUM that really forbids coexistence.
Title: Re: RPM packager
Post by: Fahrvenugen on 2011.09.02, 18:27:23
Dmik,

I do want to thank you for trying to explain the reasoning for YUM / RPM / FHS.  However a few things have still left me with questions in my mind that just don't make sense of what you're talking about.  To begin:

Quote from: dmik on 2011.09.01, 22:10:04
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.

I understand your dislike of Windows, but reading the above seems to suggest to me that you're trying to say Windows gets messed up due to a lack of FHS and / or RPM, or gets viruses due to a lack of RPM, or both.  

Of course there are viruses, malware, spyware, etc - which can infect Windows.  However I doubt it has a whole lot of anything to do with a lack of FHS or RPM.

But setting that aside dmik, one thing I'm confused abut is the mixed message we're getting.  In one message you say:


Quote
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.

Okay, so part of this is to make things easier to port apps from Linux.  No difficulty there, I can understand that.  I have used ported apps on OS/2 quite a bit and I can see the value in using ported apps.  And RPM doesn't need to be linked to FHS or the file system layout.

But then in another message you say:

Quote
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.

So according to the above quote, yes - RPM does have something to do with the file system layout - it'll dictate the layout for what it manages.

If I understand, RPM has "nothing to do with FHS", but "RPM will dictate you the FS layout for all system components it manages"

Can you please explain what seems to be 2 opposite statements?  Thanks.

Ivan,

Quote from: ivan
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.

I have to agree with you here.  For those of us who do use OS/2 as part of our jobs, where our livelihood (or a business or organization) depends on OS/2 and our knowledge of how it works, how it is set up, and how to fix it if it does happen to break (fortunately this is rare with OS/2), introducing a significant change in the file system structure - regardless of the technical reasons for that introduction (even if the reasons are sound and make sense to developers) - presents a significant risk.  I'm not saying that FHS / RPM / YUM is a bad thing.  I just share your view for caution - especially on any production system.



Title: Re: RPM packager
Post by: Pete on 2011.09.02, 20:02:47
Hi dmik

Quote from: dmik on 2011.09.01, 03:42:28

Pete, something went wrong during the installation. Either you made a mistake at some installation step (maybe you forgot to reboot?) or you have an environment that the RPM installer does not expect. If you do it right, "yum" is in PATH after reboot and you don't need to look for it in \usr\bin. Please check it once again. If the problem persists, I suggest you to open a ticket at http://svn.netlabs.org/rpm and provide more details about what you did (exactly) and your environment; this thread is not an appropriate place for that.


Found the problem: an existing "python path" in config.sys.

Having REM'd that and rebooted yum works - of course, the software relying on the now REM'd python path does not...

Regards

Pete

Title: Re: RPM packager
Post by: aschn on 2011.09.02, 20:34:56
Quote from: dmik on 2011.09.02, 15:16:09
I must explicitly state that we are *not* trying to make Linux out of
OS/2.
Dmik, please go ahead. You really know what you're talking about.

--
Andreas Schnellbacher
Title: Re: RPM packager
Post by: dmik on 2011.09.02, 21:55:20
Blonde Guy, yes, the UNIXROOT tree may live in any directory on any hard disk. It is recommended to install it to the root ATM (there may be a few exceptional applications still having something hard-coded like /bin/usr instead of /@unixroot/bin/usr that will fail if UNIXROOT is not at root -- this needs testing) but this is all fixable (we have plans to fix them all at once at LIBC level). Other than that, YUM has a Python interface which you may use to control it. RPM itself has a C interface.

Fahrvenugen, yes, sure, I love questions (and sometimes my explanations may be not clear enough indeed).

Regarding Windows, yes, I do really think that the Windows mess is a consequence of the lack of a tool like RPM. As a result, each vendor uses its own approach, installs files in a way he thinks is the best, leaves garbage all over (including system directories!), stores hundreds of MB of stuff you don't need (like the installer files) in well hidden places. All this means that if you ever installed an application, you won't be able to completely remove it later, even if you don't need it; the uninstallation procedure is never revertible on Windows. Subsequently, if you install software from time to time, your system directories will finally get so big that you will have to kill the whole installation. Everybody knows how painful it is to reinstall Windows: you need to find/download/reinstall every piece of software + a big bunch of drivers. This may take many days.

RPM (or DPKG) solves *all* of these problems. You know the origin of each file in the system, the application it belongs to, and the version of this application. If you uninstall the application, *all* its files are removed (except the application data in your user directory which includes application settings and documents you created), so you may install/uninstall as often as you like without any impact. The only thing you need to do after performing a fresh installation of the OS to get all your applications back, is |yum install <your_beloved_app1> <your_beloved_app_2> <etc...>|. A single command.

The statements you mention are not actually opposite. When I say "RPM forces the FS layout" I mean that most system packages will install files to the locations predefined by the software vendors. While RPM itself has a mechanism that allows creation of packages whose installation paths may be changed (prefixed) at the installation time, the whole model is not designed to be used that way: it is designed to not require any user interaction when installing software (which implies predefined paths). In this sense, FHS is just a logical complement to this model because it documents the standard on common system locations (so that vendors don't have to invent their own predefined paths for each new software package). Besides that, FHS happened to be used by many Unix environments (and, consequently, by many Unix programs), for similar purposes.

Pete, glad to hear that. Must be a conflicting version of some python library (wouldn't be the case if the other installation was also RPM-managed -)

aschn, thanks Andreas.
Title: Re: RPM packager
Post by: Pete on 2011.09.03, 22:16:09
Hi

Having got yum working I can see that it needs a bit of work.

Using yum to list available applications for installation results in a load of text scrolling past onscreen - not much chance of selecting an app if you cannot read the screen fast enough  :-)

I resolved that issue by directing output to a file. Having read the file I do not see anything that I currently want to install...

Out of Interest: is there a yum uninstall yum command or is that something that needs to be done manually?

Regards

Pete

Title: Re: RPM packager
Post by: David McKenna on 2011.09.03, 22:43:49
Pete said:

"Using yum to list available applications for installation results in a load of text scrolling past onscreen - not much chance of selecting an app if you cannot read the screen fast enough  :-)"

  Yes... this is the number one reason why YUM really needs a GUI to be comfortable to use on eCS IMO....

Regards,

Dave McKenna
Title: Re: RPM packager
Post by: ivan on 2011.09.04, 01:12:40
Dmik, you say
Quoteglad to hear that. Must be a conflicting version of some python library (wouldn't be the case if the other installation was also RPM-managed
Do you mean that somehow RPM is going to magically change other programs so they won't need specific versions of libraries, because I don't believe it.

I have a python path listed in config.sys and it appears, at the moment, all programs that need anything from there are quite happy with it.

I and, I expect, many other practical users of OS/2 or eCS don't want, or need, the re-invention of the wheel.  The only time I would consider changing the file system structure is if someone ported LibreOffice and it absolutely had to have a specific directory structure.

So far, apart from Java6, QT4 and those applications based on it, Paul and Ko Myung-Hun have been the people that have ported practical programs - Scribus, rsync, gcc v4.x.x and many utilities, vlc, k movie player etc, none of which mess with our boot drive image or standard directory structure.  If RPM is so good why can't it do the same?

As I have said before, our servers and workstations are our livelihood, any messing with that will not be tolerated.  Neither will anything that requires going round to each workstation just to do an update of a program - at the moment I can let the upgrade server do that overnight without any intervention on my part.   
Title: Re: RPM packager
Post by: CDRWSel on 2011.09.04, 14:44:22
Many ported programs need UNIXROOT under config.sys which is unique.
Unixroot should be program dependant and not the same coded under config.sys

Why RPM/YUM is bad ! It uses a lot of place on the disk and when you use SSD, this reduces SSD lifetime as I could see it (I have 2 SSD and checked internal counters). SSD needs lot of free space to correctly optimize nand utilization. Less nand are free, less is its lifetime.

I could see SSD out of order after just one and a half year !
SSD has a very high price compared to HD drive and it isn't acceptable to have tool for maintenance purpose only contributing into lifetime decrease for the reason above. 

If RPM/YUM could less than 10 MB as full size with unixroot removed restriction, it could become an alternative for Unix/linux programs.     
Title: Re: RPM packager
Post by: dmik on 2011.09.04, 18:20:10
Pete, having got the yum/rpm bootstrap working needs no more work than having got any other application distributed as ZIP or WPI working. So not quite clear why you explicitly mention that.

Your argument about the long output of yum is childish. Any command line application has the same problem, yum is nothing special here. But you normally don't need to list all available packages. When you want to install something, you already know its name (and you can easily limit the output to just that, see the table of commands in Wiki).

If you read the yum WPI README carefully, you will find steps necessary to uninstall it.

David McKenna, there will be a GUI soon. We significantly increased the priority of this task due to your feedback.

ivan, I said "if the other installation was *also* RPM-managed". RPM can't do anything with installations not managed by it. Regarding config.sys, see above my reply to Pete.

With RPM, you do not need to change the file structure. The RPM bootstrap (and further updates) will create the necessary structure on its own. Many programs you mentioned actually have their own UNIXROOT tree inside them which usually contains all other 3rd-party software (including system components) they need. This is bad because:

  1. It creates duplication of system components which may cause conflicts. There is no clear way to use different versions of the same DLL on OS/2, especially if they both should be loaded at the same time.
  2. Even if you manage to have two different DLL versions loaded at the same time by two different applications, some system DLLs (e.g. Qt4 or Java ones) are so big that it will have a negative impact on your system (because the shared memory area where DLLs are loaded is very limited in OS/2 and because they may use a lot of private memory for some tasks which will be duplicated) . Besides, this may also break interaction between these applications because of two copies of system data in memory.
  3. It makes it difficult for the programs to cooperate with each other (some parts of UNIXROOT are meant to be system-wide and shared across applications).
  4. Needless to say it requires putting each application to PATH/LIBPATH which requires reboots and eventually creates a mess in config.sys that you constantly need to keep an eye at (especially when you remove something from your system).

BTW, all of the above actually also applies to applications not using UNIXROOT but simply supplying everything with them and keeping it in its private directories. Yes, this is how applications are distributed on Mac but you should not compare Mac and OS/2 here. Apple has full control over the OS internals and they can optimize things to work this way; we can't. Also, a typical application on Mac doesn't have external dependencies because all frameworks Mac applications use are already supplied with the system. There is no way to achieve such a state of affairs on OS/2 (for obvious reasons).

RPM can do exactly the same of course, but since it is what we consider a bad thing, we do not want to do that. We ported RPM to solve the above problems, not to keep creating them.

All programs you mention, distributed as they are, require careful manual setup which sometimes may be hard if you are not an expert. Even if you are, you can simply mistype a single slash or a semicolon and that will break the installation. I don't know why you find this exciting.

I didn't fully understand what you were saying about the server updates. If you mean that in your infrastructure workstations run their software from the network drives so that updating the server causes all workstations to be updated, then RPM lets you do exactly the same but but in a much better way (by at least removing all the problems related to the need to run the software from a network drive).

CDRWSel, about UNIXROOT and config.sys, please see above.

Regarding the hard disk space taken by RPM. If you mean the fact that the current RPM repositories cause RPM bootstrap to install GCC binaries and LIBC headers on your machine, this is a bug and it will be fixed.

I fully understand your concerns about SSD, but it is not clear to me why you find RPM guilty here. It will only perform actions when you ask it to do so. Otherwise, it does nothing.

Regarding SSD per se, I must say that UNIXROOT is a *big* helper in this area because of its strict structure. There are basically two directories in FHS which get written to during normal operation of the OS: /var and /tmp (and /home of course); programs are not allowed to write to other directories (and under Unix/Linux they simply can't). For SSD it's just perfect: you move these two directories to a device that is fine with frequent writes (e.g. to RAM-disk) and live happily.
Title: Re: RPM packager
Post by: Pete on 2011.09.04, 21:07:47
Hi dmik

I mentioned that I got it working because when 1st installed it did not work due to the python path that already existed in my config.sys file. I would have expected yum/rpm to look for python within the UNIXROOT\bin or UNIXROOT\user\bin directories.

Your point about installing something is rather lame. I do *not* know what packages are available therefore I do *not* know any package names and could not simply issue a command to install a package.

As for uninstalling: Yes, it is gone.

Regards

Pete


Title: Re: RPM packager
Post by: CDRWSel on 2011.09.05, 02:51:36
I need most space as possible on the SSD for SSD safety and if you look the required space by RPM/YUM, very big.

I need each programs (full) in its own path and not parts of program under a same path (unixroot). I need to preserve what was the interesting part of OS/2 - eCS which was the possibility to move the program path under an other path with a single drag/drop.

RPM/YUM is not able to do this and uses process like older windows resulting into overwrite of dll or changed dll no more usable by some programs etc...

Windows is now going out of this process due to lot of problems and if you see how many  people are interested by portableapps, it should tell you that you are going wrong !

Today, the best installer is warpin (very easy and realy end user oriented while RPM/YUM is developper and server oriented)
No need to unzip programs and do manual updates because all these steps are done by warpin.
Title: Re: RPM packager
Post by: dmik on 2011.09.05, 03:30:22
Pete, thank you, we will add a line to README that all previous installations of python need to be removed.

I think you misunderstood me again. If you want to install Java, you type |yum search java| and it will show you the exact names of the packages whose descriptions or summaries contain the word "java". If you don't know the name of the program you want to install but still want to install it, well, this is unusual, as I said.

CDRWSel, what is your definition of "very big"?

It was never possible to move the program to a different location with drag & drop on OS/2 (except very trivial programs that don't have entries in config.sys and don't have WPS objects).

What you say about RPM/YUM further shows that you have neither knowledge nor even basic understanding of what RPM/YUM is (and you don't seem to know WarpIn well too). I'm not going to repeat everything once again, sorry. Please read the respective sources of information on the Internet and ask questions if you have them. Your words about portable applications show that you have weak understanding on how they work and also that you don't read what I write to other people. Please do.
Title: Re: RPM packager
Post by: CDRWSel on 2011.09.05, 04:46:16
dmik

I used RPM/YUM several times and removed it due all previous objection. I wrote warpin package too. About 60MB on a SSD disk is very big just for installation/updates ! (of course, you comments about some path put on ramdisk will prevent unnecessary write operation but it will not free space on the SSD for other programs with need to write on it. Garanty of enough free space on SSD is garanty of long working disk)                

1/ I do drag/drop of many programs and not only some trial programs. OS/2 user since OS/2 2.1

2/ When I read "If you want to install Java, you type |yum search java|"  Is this End user oriented ? surely not while End-user means "click on an icon" like "eCo Market"

As I wrote, RPM/YUM could be interesting when installed on a server and for me, it isn't for home user or single workstation.

About portableApps, I use it since several time and configured several friends USB key and made my window application as portableapps. Do you use it ?

Now, if you try go backward into this thread, may be you have the same errors as I have:

8: Undefined offset: 0
File : /home/os2worldcom/httpd/html/components/com_smf/smf.class.php
Line: 449
...
Title: Re: RPM packager
Post by: CDRWSel on 2011.09.05, 06:35:40
What should be the correct approach of a developer ?

- Propose an idea and check if it is welcome for end-users
- Provide a draft and check what's ok or not
- Take all End-users comments and change the product to make it conform and desirable
- End-user can have great idea and it is worth to add them into the project 
- Don't critic end-user
- It is the end-user which better know what is good for him
- The end-user is the one which is going to buy and use the product

I know a specific windows programs, developers tried to impose they solution (they know what is good, end-users do not), add automatic update and later blocked programs to work if no web connection and finally, they took user system information (ip@, os version etc...) and finally, as soon the hardware and windows changed, the tool no more worked and through the web connection, a warning message was issued about license violation ! Today, the product is at his end and no more development exist... The security was impacted here ? web connection ! user system information taken etc...

Remember, the decider is the End-user and not the developer. The problem with RPM/YUM is that lot of time was spent on porting RPM/YUM without asking end-user if it would be ok for all. This could explain why it is tried to impose it despite many reject !
Title: Re: RPM packager
Post by: melf on 2011.09.05, 09:47:26
FYI! As Remy and others have pointed out and you all see for yourselves, there is problems with forum threads. I know that Martin is working on a migration to a new platform, but this may take its time. To reach earlier pages in this thread please enter www.os2world.com/forum in your address field to go straight to the forum (this way should work). You'll find this thread under "Setup & Installation". We are sorry for the inconvenience.
Title: Re: RPM packager
Post by: gamba on 2011.09.05, 10:22:09
Quote from: ivan on 2011.09.04, 01:12:40

...

So far, apart from Java6, QT4 and those applications based on it, Paul and Ko Myung-Hun have been the people that have ported practical programs - Scribus, rsync, gcc v4.x.x and many utilities, vlc, k movie player etc, none of which mess with our boot drive image or standard directory structure. 

...


Ever tried CUPS? It works very well but I was never able to install it out of root. Obviously, dmik is talking about complex software.

Bye
Gabriele
Title: Re: RPM packager
Post by: dmik on 2011.09.05, 15:01:17
CDRWSel, yes, bootstrapping RPM takes about 60MB. But this includes Posix coreutils besides RPM itself plus some system DLLs needed by all programs. It's a bunch of useful command line tools which we have to provide because the OS lacks them.

Regarding DnD. I already mentioned that you can't DnD programs which need a specific environment that depends on their location (PATH/LIBPATH/WPS). Besides, it is not fully clear why you need keeping to DnD your programs around. Possible answers (I'm guessing since you are not specific):

1. To maintain your own order of things, as lewhoo already mentioned here. My question: why dragging & dropping the WPS objects of programs instead is not enough for you?
2. To be able to easily transfer the program from one PC to another. Our answer: with RPM you don't need to do such manual transfers. If you still want it for some reason (you are in the forest with no Internet connection), you can take the raw .rpm file and install it. The raw .rpm file is much like the .wpi file. The YUM/RPM GUI will include a simple interface to install it by double click w/o the command line.
3. To backup. Our answer: you don't need to backup software with RPM. You may easily recreate the exact installation of your software with a single command (mouse click, once GUI is ready).
4. To optimize hard disk usage. Our answer: this is not a user-level task. Hard disks are extremely cheap nowadays, just buy a bigger one and copy your OS/2 over to it. If you want to use the bloody expensive SSD gear, you want something unusual and you have to learn how you can optimize FHS and things for it. The cost of maintaining all software in the world easily relocatable on OS/2 is orders of magnitude higher than you could pay for that.
4. I ran out of ideas here. Feel free to add something.

The command line interface of yum is very well user-oriented.

Regarding your question about portable apps, no I don't use them since I don't need it. And I don't know people around me that would use them, frankly. There are very few cases where it would be necessary. In either case, creating an USB stick with the portable application on it has nothing to do with RPM. The level of work it requires depends on the software you want to make portable. RPM can add more work here, but since it is not something needed very often, we don't care too much about that.

What you say about the developer's approach is true (with a few obvious exceptions) but only when it comes to the UI (*user* interface). Everything else is none of the user's business. What you say about the stupid Windows Update system has nothing to do with RPM. Nothing.
Title: Re: RPM packager
Post by: CDRWSel on 2011.09.05, 23:57:07
SSD is no more something unusual and it become more and more current here and specialy into netbooks !

Today, SSD has many advantages (ans some inconveniences) like High speed, low temperature, low power need, no vibration, better chock resistance etc...

This is why use of older FHS + RPM/YUM and its structure is again not a good idea because this was developped using older HD. It looks like you try to impose something old as a revolution !

Better would be to create something new using some part of the RPM/YUM idea but making it like a revolution program integrating SSD requirements (auto optimizing SSD usage and not left the end-user to tune his configuration him self) and of course End-user option to have they program where they would like including an FHS structure for those making this choice. E.g. with 4 partitions, you could have eCS under one partition and productions programs like openoffice (what about libreoffice on eCS ?) on a second partition and some beta programs or games or user programs under a fird partition. The 4th partition could have datas on it etc...

Imagine the satisfaction if a tool like this could be available, other OSes would like buy you a license to use it !
Title: Re: RPM packager
Post by: aschn on 2011.09.06, 00:08:50
Quote from: CDRWSel on 2011.09.05, 23:57:07
auto optimizing SSD usage

Remy, are you sure you weren't getting off-topic?

(I really don't want an installer to do tasks like that.)

--
Andreas Schnellbacher
Title: Re: RPM packager
Post by: dmik on 2011.09.06, 02:47:19
CDRWSel, I already told you that FHS suits the needs of optimizing SSD usage better than anything else. No need in revolution, just map /home, /var and /tmp out of SSD (actually, you can already do it in eCS with the path rewriter tool) and you will get what you describe as satisfaction. RPM is not involved here at all.
Title: Re: RPM packager
Post by: CDRWSel on 2011.09.06, 16:46:28
aschn

Well, I think not having used the right expression and what I mean with is propose and use specific path needing lot of write operation by the product (e.g. temporary path.. ) on not SSD disk if available (of course, end-user should have hand of this)

For easy use, GUI should be able to do what's needed and command line mode should only be a special mode reserved for expert user.
Title: Re: RPM packager
Post by: Fahrvenugen on 2011.09.06, 19:14:29
Quote from: dmik on 2011.09.05, 03:30:22

It was never possible to move the program to a different location with drag & drop on OS/2 (except very trivial programs that don't have entries in config.sys and don't have WPS objects).


I disagree -  I drag and drop entire OS/2 based apps all the time and rarely have a difficulty.  This is one of the features of OS/2 that sets it apart from  other operating systems - it easily allows you to do this - move around either data files or entire apps without breaking things (and it even updates your shadows and objects properly) - all due to the OO technology built into the system and WPS.

Admittedly it doesn't work as easily on ported apps - mostly because ported apps often rely on configuration files which define the app locations.  In those cases, it not only requires drag and drop of the app, but also updating the config file(s).








Title: Re: RPM packager
Post by: ivan on 2011.09.06, 19:54:32
Dmik,
60 MB for an installer - you have to be joking - Warpin is less than 8MB.  As for command line utilities - this is OS/2 a GUI interface remember.  You may be 'into' the command line but most users are not.

This, coupled with the 'I'm the developer and I know what you want' attitude is pointing this project in the direction of it being a developer ego trip or vanity project - I'm doing it because I can.

If you were blowing your trumpet and saying 'I have a working alpha version of LibreOffice 3.3', then I think everyone would be cheering you on, but you're not and we're not.

You said that one of your aims was to make OS/2 more relevant.  If that is the case you have the cart before the horse.  What is needed are things like LibreOffice, TurboCASH, ARCAD, Stellarium, Sweet Home 3d, Gimp, Google Earth, ABBY FineReader Engine, VirtualBox as well as those we already have ported.  Those are the type of applications that will rejuvenate OS/2 in the business environment - not a fancy installer.

I have given much thought about posting this but in the end decided to do so because here we have a testing process in which we throw every objection we can think of at a project and if it survives that we let it continue and see how it develops.

-----------------------------------------------------------------
Yes Gabriele I have but not on the boot drive - see the readme with cups:
Limitations:
CUPS must currently be installed in the root directory of a drive, ie \cups

It works quite happily from drive I on my teat machine.       

ivan
Title: Re: RPM packager
Post by: dmik on 2011.09.06, 20:51:59
Quote from: Fahrvenugen on 2011.09.06, 19:14:29
I disagree -  I drag and drop entire OS/2 based apps all the time and rarely have a difficulty.  This is one of the features of OS/2 that sets it apart from  other operating systems - it easily allows you to do this - move around either data files or entire apps without breaking things (and it even updates your shadows and objects properly) - all due to the OO technology built into the system and WPS.

We do not speak about WPS here, we speak about moving applications from one folder to another on the hard disk.

ivan, the joke here must be your concern about the installer size. RPM itself is only several MB. The rest is Posix core utilities and libraries needed for many other software. Counting them together has as much sense as counting together WarpIn and all DLLs in \OS2\DLL.

"'I'm the developer and I know what you want" -- first, neither me, nor other devs said that, so please don't refer to it. Second, now we do know what you want indeed, after you have told us (if you were not lying, of course). Third, we do know what some other users want because they told us too. Fourth, we do know what we need to do on the system level in order to deliver software of a certain quality. We know this better than an average user not because we're just cool but because this is our job and we have experience. And, BTW, refusing to trust the developer in this area may leave you with no chances to ever have LibreOffice 3.3 and other things you listed. Just so that you thought of that too. Our work is partly sponsored by the community and we feel great responsibility before it for what we do. But to do our best we should be trusted.

Saying more on that would be off topic here, so if you want to continue this discussion, feel free to start another thread. Regarding the test process, this is part of the idea, keep throwing. But please don't repeat the same thing over and over again -) It just wastes your and our time. Thank you for understanding.
Title: Re: RPM packager
Post by: CDRWSel on 2011.09.06, 22:39:48
dmik
About drag and drop, Irvan is correct but you aren't
You wrote:"We do not speak about WPS here" of course I do and if you didn't understand it, then you are unable to understand us ! How are you going to make you application drad/drop portable (of course WPS) ?

Of course you suggested and wrote that you are the developer and know better as end-user what is better for them ! and again you wrote it in this way "refusing to trust the developer in this area may leave you with no chances to ever have LibreOffice 3.3 and other things you listed" once again, Irvan has right

Are you serious when you wrote "Counting them together has as much sense as counting together WarpIn and all DLLs in \OS2\DLL" ? may be you don't know there is a ecs\dll path very usefull to put all dll's under it like I do by default. What is the sense to add new path for dll while 2 path already exist ? none. Many programs are able to perfectly work with DLL under the program path (of course, these dll should be program specific dll to prevent mixed dll level for which ecs\dll or os2\dll path are good)    

You wrote that not going in the way you would like dictate us will make Libreoffice not work !
I hope it is a joke or just explain how portableapps could install libreoffice 3.4.2 without using your tool ? nor using fhs structure ? and it works perfectly and has great success despite it is windows ! (Oh, right, you don't know how portableapps works and not interested how they do because they is no rpm/yum like process in it ! but, may be you could have a look on the process they developed to easy package installed application into a portable application). The arguments you are using are unacceptable.

More interesting is they new beta interface which allow to check for programs update. One click, it returns then all installed application which have been update and propose to make the update or (each one could be unselected). Click yes and all programs are auto-updated... This all function uses very litle space on the usb key, try it out and may be you'll change you mind and gives you good idea for a realy new,small and best update tools on the world !
   
Please come down on earth....  ;D
Title: Re: RPM packager
Post by: dmik on 2011.09.06, 23:27:30
CDRWSel, sorry but it is really hard to understand you because your English is very bad and it makes your words often contain no sense. WPS objects are completely unrelated to FHS, you will still be able to drag'n'drop them, even if the application is installed with RPM. More over, this is what we suggest you to do instead of taking care about real directories on your hard disk.

I am absolutely serious when I write something here. It looks like you also have problems with reading English, not only with writing. Either you do something with it (ask somebody to translate what I write and what you want to write), or I will not be able to continue the discussion with you. Sorry again.

I would like to add a word about dictating though (as this part of your speech I understood). Stop saying lies please. We do not dictate, we provide alternatives. For those people who needs the software we port and supports our work we will be providing two formats: ZIP and RPM. This will give people a plenty of choices: plain old ZIP for managing their own carefully cooked layouts or for creating portable applications, and RPM for those who wants all the dirty work done for them. If your only concern with RPM is the lack of GUI, you should better support us so that the GUI appears faster (there will be a prototype very soon to let you know how it will look and feel).

If you just want ZIP with the GUI interface (this is what WarpIn, given its limitations, effectively is) this is not what we can currently offer you, because it will only cause failed installations and nothing more. We know that, we have a lot of experience with Qt4 and other programs we distributed as WPI. Sorry about that.
Title: Re: RPM packager
Post by: CDRWSel on 2011.09.07, 00:49:44
Now, without argument, you decided to attack my poor English l  Shame on you   

I know my English is not perfect but most user here could understand what I wrote or mean me ! You are really insincere and your ego is to high.

I promote and did more for eCS, I paid Openoffice support agreement and you convict me today to stop pay for something I don't want and never was announced going this way on mensys link. I developed applications for eCS and I did it with end-user feedback and suggestions to satisfy they need...

Yes, I prefer stop talking with you.I prefer use my time in development.
Title: Re: RPM packager
Post by: melf on 2011.09.07, 01:01:45
dmik,

As far as I understand your aim it is to implement the RPM installer in order to ease installation and updates of both *nix ports and native os2-software. To better suit *nix-ports you also want to implement FHS as the directory tree standard in eCS. Morover the eCS command line will be replaced by "e.g. sh.exe instead of cmd.exe", while the eCS command line will be left for compabilitity reasons.

Many users of eCS have used OS2-eCS for a long time and have developed habits in their use and ways to manage problems. I guess that quite a few rely on eCS for their business investments. In total many eCS users also have a grounded knowledge of their OS. Morover eCS is not just any OS, it is an OS into which people also have invested a great deal of feelings, we all know that and the reasons why.

 
I don't distrust your good will and effort to provide eCS with more software, but I wish you would understand peoples feeling about your idea. You are trying to argue in an over-rational way while not being able (or willing) to understand the resistance you meet. You are forcing to people a *nix layout and way of thinking and handling software. Morover you take the ordinary eCS users grounded knowledge from them as things become lesser transparent (RPM knows but not you) and lesser flexible (can't organise software the way you want), in that way hampering their work habits and ways to deal with problems. For many eCS users this is provoking - it is a little bit like saying to someone: "from now on you should speak spanish (or whatever language), you can't use your language anymore".

I think it would be good if you stopped arguing for a moment and tried to listen. RPM might turn out to be good, but eventually implemented in another way -  a way that is acceptable to users and can preserve OS2-eCS values - both practical and emotional.You may say that the use of RPM is voluntary, and of course it is, we can choose not to use it. But on the other hand you can choose too, you can choose to listen to what people are communicating.
Title: Re: RPM packager
Post by: dmik on 2011.09.07, 05:32:32
melf, your basic understanding of our idea is correct.

But I don't know what makes you think that we don't understand your concerns. The fact that we don't want to go the old way doesn't mean that we don't understand it (personally, I've been using OS/2 since 1993 and I had exactly the same concerns regarding RPM and FHS as you some time ago, even after getting some good Linux experience). What I want to say is that we are not able to provide quality software for the old OS/2 environment without changing it in some ways -- can it be more clear? Almost all system components in OS/2 are outdated, bogus and have limited functionality. This includes the base and the GUI libraries, the command line tools, CMD.EXE, the file system layout, config.sys and lots of other things. At some point this made the task of writing/porting the new software to OS/2 unmanageable. So, for us, the changes we are proposing are inevitable. You got it wrong. We didn't ask you about what file structure we should use on the boot drive and which installer framework we should port. What we are asking you about is this:

1. What are your most important concerns regarding RPM? We will listen and provide a solution, when possible, if it does not already exist.
2. How can we make this transition easier for you? We wish it to be as easy as possible for the end users.
3. What do you want to know about the upcoming changes? We are ready to help you and we want to give you understanding of things.

These are the current concerns we see, and our answers to them:

1. No GUI. -- Point taken, this is being worked on. Please, |yum install| until then.

2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).  -- Please believe us, you will not want to do that after getting used to RPM. Given the size and the price of modern hard disks, it is not a problem to just get a bigger one to fit all you need. We may also come with a solution to at least select the target drive later (when the GUI is done).

3. No way to select the installation directory (I want things to be sorted *my* way).  -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like. See also 5. and 6.

4. I hate FHS. -- If you look at that carefully, it's just *two* new directories (/bin, /usr) in the root. /etc, /tmp, /var and /home don't count because they already exist in eCS (/etc and /tmp even exist in the original OS/2 under slightly different names). Two new directories is not that much, is it?

5. I hate application files spread across different directories. -- We know this is unusual for you. We agree that keeping all files in a single directory simplifies housekeeping, but this is not always possible on OS/2 due to some native limitations that we can't fix. And given that RPM always knows what files comprise the application no matter where they are, it does not actually make housekeeping (installing/uninstalling) more difficult in its case. If you are concerned about moving applications around for sorting purposes, see answers 2. and 3.

6. I not only want sorting, I also want to be able to quickly move the application to another machine. -- Let RPM do it. Given its knowledge about application files, it will be faster than you (and no removable medium is necessary).

7. I want to use the application on a machine where I have no Internet connection. -- Take its .rpm file. It is really easy to install the application from it w/o the Internet connection.

8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

9. I don't want automatic software updates. -- RPM doesn't do that. It only behaves if you ask it to.

10. I want full manual control. -- We also provide ZIPs for all applications.

11. No transparency of things. -- Everything is transparent, it is a matter of learning a couple of RPM commands. Will not be necessary when the RPM GUI comes up.

12. You are ****. -- We love you too!

As you see, all your current concerns have or will have solutions. Yes, it requires you to slightly change your habits and to learn something new. But we sincerely believe this is for your own best and we will try to minimize the learning curve. Eventually, this will make your OS/2 life easier. And it will surely prolong the life of OS/2 itself.

CDRWSel, you are ignored.
Title: Re: RPM packager
Post by: Fahrvenugen on 2011.09.07, 07:44:55
Quote from: dmik on 2011.09.06, 20:51:59
Quote from: Fahrvenugen on 2011.09.06, 19:14:29
I disagree -  I drag and drop entire OS/2 based apps all the time and rarely have a difficulty.  This is one of the features of OS/2 that sets it apart from  other operating systems - it easily allows you to do this - move around either data files or entire apps without breaking things (and it even updates your shadows and objects properly) - all due to the OO technology built into the system and WPS.

We do not speak about WPS here, we speak about moving applications from one folder to another on the hard disk.



Yes, that is exactly what I often do.

I'll install an app into a folder on the hard drive and later drag it to another folder on the same drive and it'll still work.

Or I'll drag it to another drive with a different drive letter, into a different folder, and it'll still work.  And all the objects on the desktop for that app get updated too.

So yes, I do know what I'm talking about - moving applications from one folder and / or drive letter to another, using drag and drop.  And yes, it does work for many OS/2 based applications.

I've used this technique to test apps before using them in production.

I've also used this to deploy apps that run from a network share - set them up on my local machine, copy the app over to a network share, then add an object for the app to all the desktops available on the network (and doing this involves a single command).

Anyways...

Please understand that I'm not trying to attack or be overly critical of RPM / YUM - I'm just trying to offer a view of some of the ways that - as an OS/2 / eCS user - ways that I currently use the OS.  I'm also understanding more that RPM / YUM is one of those things that is ultimately up to the end user if they want to install and use in the first place.  Those who want it can use it, those who prefer not will likely not use it,  just as developers who prefer to distribute their installers with ZIP / IBM Installer / WarpIn / Feature Install / a plain old REXX script / etc will likely distribute with their choice of installer.


Dmik, also please don't misunderstand me.  I do appreciate all the work that you and other developers are doing to keep the system relevant and useful.  I admit that I do share some of the concerns that have been expressed, and as a result I likely will be one of the more cautious users when it comes to RPM / YUM. However I also don't want this to be a deterrent to development.  Each user will have different needs and comfort levels when considering introducing new software on their system(s).  Just as some users will have DOS and WinOS/2 support installed and some users won't install it, some will install Java and some won't, I can see YUM / RPM falling into a similar category.

Title: Re: RPM packager
Post by: CDRWSel on 2011.09.07, 09:38:35
I just read dmik arguments and answer, as I wrote, he's adapting and older process to eCS.

The base idea is not bad (and well developer oriented) but the implemented process and how it should work needs a lot of work and add flexibility needed by end users (as read under this thread) to go in the direction other OSes developers are taken, more flexibility and portability  

Some Companies are know looking how to install applications on removable storage for portability which is part of the futur. End user plugin his USB removable storage on an available hardware (like wifi is now free accessible) and have the personal desktop ready.
Of course, the removable storage would be very secured when encrypting all data using a PGP tool.    

The other direction would be tablet system (it looks like a revolution and easy to use for resellers and home use) which mostly use android OS or apple OS. The OS has to be responsive and small in size on the burned in SSD chips.
Title: Re: RPM packager
Post by: ivan on 2011.09.07, 13:17:12
dmik,

QuoteThese are the current concerns we see, and our answers to them:

1. No GUI. -- Point taken, this is being worked on. Please, |yum install| until then.

No comment.

Quote2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).  -- Please believe us, you will not want to do that after getting used to RPM. Given the size and the price of modern hard disks, it is not a problem to just get a bigger one to fit all you need. We may also come with a solution to at least select the target drive later (when the GUI is done).

This is only relevant in a single user concept.  Business use has a different usage pattern that is usually a boot partition that is kept as small as possible and is transferred from an image file to the target machine.

Quote3. No way to select the installation directory (I want things to be sorted *my* way).  -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like. See also 5. and 6. 

Not good enough!  We have images of the tools directory and its structure as well as the utilities directory which can be placed on target machines as necessary - your idea is still single user.

Quote4. I hate FHS. -- If you look at that carefully, it's just *two* new directories (/bin, /usr) in the root. /etc, /tmp, /var and /home don't count because they already exist in eCS (/etc and /tmp even exist in the original OS/2 under slightly different names). Two new directories is not that much, is it?

All you are doing here is fragmenting programs (see also 5).

Quote5. I hate application files spread across different directories. -- We know this is unusual for you. We agree that keeping all files in a single directory simplifies housekeeping, but this is not always possible on OS/2 due to some native limitations that we can't fix. And given that RPM always knows what files comprise the application no matter where they are, it does not actually make housekeeping (installing/uninstalling) more difficult in its case. If you are concerned about moving applications around for sorting purposes, see answers 2. and 3. 

You might have a small argument to do this on a single system - it does not work in any business situation I know of.

Quote6. I not only want sorting, I also want to be able to quickly move the application to another machine. -- Let RPM do it. Given its knowledge about application files, it will be faster than you (and no removable medium is necessary).

Again, this is not for use in a business.

Quote7. I want to use the application on a machine where I have no Internet connection. -- Take its .rpm file. It is really easy to install the application from it w/o the Internet connection.

You will find in business what you are suggesting does not work - the admins have control of what may, or may not, be installed and the company firewall tends to stop the acquisition of things from the internet.

Quote8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

Again single user thinking, it won't wash in a business.

Quote9. I don't want automatic software updates. -- RPM doesn't do that. It only behaves if you ask it to.

10. I want full manual control. -- We also provide ZIPs for all applications.

11. No transparency of things. -- Everything is transparent, it is a matter of learning a couple of RPM commands. Will not be necessary when the RPM GUI comes up.   

Yet more single user thinking.

Have you actually asked sys admins of businesses how they administer their IT?  Because as I read it you are focused on single user usage only.

Title: Re: RPM packager
Post by: dmik on 2011.09.07, 14:00:39
Quote from: Fahrvenugen on 2011.09.07, 07:44:55
So yes, I do know what I'm talking about - moving applications from one folder and / or drive letter to another, using drag and drop.  And yes, it does work for many OS/2 based applications.

I didn't say that this does not work. You probably don't remember, but I said that this will only work for simple apps with no dependencies. This is not the case for modern apps we provide. Even a trivial kdiff3 utility needs the Qt4 runtime. Packing the Qt4 runtime with each application will increase its installed size by 40-50 MB even if the application itself is 500 K. This is insane and this will create an incredible mess of DLLs on your system.

Quote
I've used this technique to test apps before using them in production.

You don't need this technique with RPM. You can safely install/uninstall as many times as you want. Uninstalling the application will bring your system to the exact state it had before installing (except that the configuration file in /home/user, if any, will not be deleted, but this can't harm).

Quote
I've also used this to deploy apps that run from a network share - set them up on my local machine, copy the app over to a network share, then add an object for the app to all the desktops available on the network (and doing this involves a single command).

You don't need network shares to deploy apps this way with RPM. And this gives you significant benefits.

Thank you for your appreciation.
Title: Re: RPM packager
Post by: dmik on 2011.09.07, 14:50:25
Quote from: ivan on 2011.09.07, 13:17:12
Quote2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).

This is only relevant in a single user concept.  Business use has a different usage pattern that is usually a boot partition that is kept as small as possible and is transferred from an image file to the target machine.

The whole concept of the managing software installer is rather irrelevant in this usage pattern since the master image is static and carefully hand crafted anyway. But you still benefit a lot from RPM here because it allows to do *controlled* installs and structured updates of any software. This may simplify things when creating the master image and it also lets you deploy some applications right on the target workstations w/o the need to recompose/retest/redeploy the master image, which is obviously much faster and requires much less effort.

Quote
Quote3. No way to select the installation directory (I want things to be sorted *my* way). -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like.

Not good enough!  We have images of the tools directory and its structure as well as the utilities directory which can be placed on target machines as necessary - your idea is still single user.

The quoted answer is for the single user indeed, and not for your case at all. For you the answer is above. RPM lets you manage the images of such tools directories much more effectively than any other instrument you currently have. Much more effectively means less money on support.

Quote
Quote5. I hate application files spread across different directories.

You might have a small argument to do this on a single system - it does not work in any business situation I know of.

What do you mean when you say "a small argument"? I already presented many big arguments for doing so. Please read my posts. And what do you mean when you say that it doesn't work in business? It is not clear from your vague answer.

Quote
Quote7. I want to use the application on a machine where I have no Internet connection. -- Take its .rpm file. It is really easy to install the application from it w/o the Internet connection.

You will find in business what you are suggesting does not work - the admins have control of what may, or may not, be installed and the company firewall tends to stop the acquisition of things from the internet.

You seem to not understand what you are citing. I said that you *don't* need the Internet connection to have the ability to use RPM managed software if you want so. Regarding "what may, or may not, be installed", RPM gives you precise control over this. You probably don't remember but I already wrote that you can easily create your own RPM repository located in your intranet behind your firewall and stuff it only with the software you trust and need.

Quote
Quote8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

Again single user thinking, it won't wash in a business.

This sounds like naked words to me. Please clarify what you mean.

Quote
Have you actually asked sys admins of businesses how they administer their IT?  Because as I read it you are focused on single user usage only.

I already said that we are focused on *general* usage. This includes the generic patterns of both personal use and business use. Most complaints here are from "single" users, hence are our answers. For you we have different ones.
Title: Re: RPM packager
Post by: CDRWSel on 2011.09.07, 16:09:53
Because I spoke about portableapps, here is a comment I would like more often see from some developers under my prefered OS.

Customizable App Organization With Automatic and Custom Folders
You asked for it, you got it

The menu which includes install/uninstall/update applications only uses 4MB as compressed file. Here is the link which, I think, could give good ideas and improve our prefered OS.
http://portableapps.com/news/2011-08-08_-_portableapps.com_platform_2.0_pre-release_3_released (http://portableapps.com/news/2011-08-08_-_portableapps.com_platform_2.0_pre-release_3_released)  
Title: Re: RPM packager
Post by: lewhoo on 2011.09.07, 16:19:21
Just to give a notice, I am familiar with RPM and yum, I have to use it nearly every day in it's native enviroment, so moslty the new thing I'll have to learn will be the GUI installer.

Quote from: dmik on 2011.09.07, 05:32:32

2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).  -- Please believe us, you will not want to do that after getting used to RPM. Given the size and the price of modern hard disks, it is not a problem to just get a bigger one to fit all you need. We may also come with a solution to at least select the target drive later (when the GUI is done).

Simply not true. I just could say that, because I know much better how I fill using yum/rpm on linux and what I want. But I'll give some arguments:

1. small disks on notebooks, not easly changable
2. Multi-system installs
3. And finally - I always hated argument "just buy a new hardware". This is Microsoft argument. This is the way that most linux and windows software became badly written and unoptimized. I don't like buying new hardware because I am forced to. For me, many times, changing to a new hdd ment changing the whole machine.

Quote
3. No way to select the installation directory (I want things to be sorted *my* way).  -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like. See also 5. and 6.

For me this is not the solution. This is a fundamental change in the OS and, I am completely sure of that, a downgrade. Linux was made to be managed by an admin, who posseses magical knowledge, not simple or even experienced (power) users. Now they attempt to make some workarounds around this fact. Here you try to implement such a workaround on a system,which has completely different idea behind it's design - here I am an admin, but an admin who does not have to possess all the magical knowledge and spend 10 hours a day learning it's system, to get things organized as I like in my system. I am a power-user. For me, one of your main tasks should be allowing power-user to remain the main user of OS/2. Older software allows that. I know this can be difficult with unix-ported software, because no idea of power-user exists on linux/unix. But that's a big part of core of what OS/2 is and why it is unique. And pleasedo not say - you will have a zip package. Resolving dependences manually and so on is most of the time task managable by an admin,not a power-user.


Quote
5. I hate application files spread across different directories. -- We know this is unusual for you. We agree that keeping all files in a single directory simplifies housekeeping, but this is not always possible on OS/2 due to some native limitations that we can't fix. And given that RPM always knows what files comprise the application no matter where they are, it does not actually make housekeeping (installing/uninstalling) more difficult in its case. If you are concerned about moving applications around for sorting purposes, see answers 2. and 3.

So please make a browser of RPM "knowledge" with some kind of app like FC/2. With which I could move files around, see where file belongs, get apps automatically updated with information where their files now are. Well, I know that this would be a work comparable to writing the RPM from a scratch, so this is just to give you a hint. So for the beginning, just simplify getting files informations from RPM with a gui installer - I mean, don't leave us with a pure command-line (or GUI) listing,which we have to parse with our eyes or grep/awk/less, as is a common situation on linux.

Quote
8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

How about backing up user data?


I think I could appreciate OS/2 version of RPM/YUM (not a port, a version), that would have reasonable gui, allowed to install every file where I want it to, and allowed me to browse every info I want in a human-readable way. This is my personal opinion as an end-user.
Title: Re: RPM packager
Post by: lwriemen on 2011.09.07, 16:55:14
I don't understand the all or nothing approach. Maybe that's not what's being proposed, but it has read that way.

Let %UNIXROOT% be where the FHS is placed. Ideally use a volume (right term?), so it can be re-sized larger if more hard drive space is needed. Let all the ported *nix apps play within %UNIXROOT% and leave the OS and all native apps to the usual arrangements.

I hated the PROGRAMS directory eComStation introduced; it was a Windows artifact, and not how OS/2 works. Forcing everyone onto the FHS would be another illogical, unnecessary change. Let OS/2 be OS/2. It can support many things at once.

Now anyone who wants *nix ports to behave like OS/2 apps, get over it! They are ports, and they weren't made for OS/2! If the ports are made easier by installing the FHS somewhere, then that is a benefit for all. The wishlist for a rpm/yum front-end can be started, so you can specify (e.g.) where to place the shadow for execution during install.
Title: Re: RPM packager
Post by: Fahrvenugen on 2011.09.07, 17:12:59
Quote from: dmik on 2011.09.07, 14:00:39
Quote from: Fahrvenugen on 2011.09.07, 07:44:55
So yes, I do know what I'm talking about - moving applications from one folder and / or drive letter to another, using drag and drop.  And yes, it does work for many OS/2 based applications.

I didn't say that this does not work. You probably don't remember, but I said that this will only work for simple apps with no dependencies. This is not the case for modern apps we provide. Even a trivial kdiff3 utility needs the Qt4 runtime. Packing the Qt4 runtime with each application will increase its installed size by 40-50 MB even if the application itself is 500 K. This is insane and this will create an incredible mess of DLLs on your system.

So essentially from what you're saying this isn't all that different from apps which use the OS/2 system DLL's, emx DLL's, the Libc dll, etc.  The apps will need to be able to see the libraries they use.

Quote
Quote
I've used this technique to test apps before using them in production.

You don't need this technique with RPM. You can safely install/uninstall as many times as you want. Uninstalling the application will bring your system to the exact state it had before installing (except that the configuration file in /home/user, if any, will not be deleted, but this can't harm).

I understand what you're saying, but in a production environment I wouldn't deploy an app until properly tested on a system set up for testing stuff. But this has little to do with RPM / YUM though - it would apply equally for any application regardless of how it is installed.

Quote
I've also used this to deploy apps that run from a network share - set them up on my local machine, copy the app over to a network share, then add an object for the app to all the desktops available on the network (and doing this involves a single command).
Quote
You don't need network shares to deploy apps this way with RPM. And this gives you significant benefits.

Thank you for your appreciation.


On this point, I think you're not fully understanding me.  I'm not talking about deploying and installing an app from a network share on individual workstations.  I'm talking about having the app sitting on a network share and running it directly from that share.  The app does not get installed locally on the workstation - it sits on the network, and can have multiple workstations running the same app (accessing the application EXE's and DLL's through the network).

The reasons for this can be multiple.  For security, you can easily control what apps can be run on what workstations and by what users based on the user login and the groups the user is a part of.  If an update or change needs to be made to an app, you only need to update / change / fix the app in one place and everyone gets the update (no need to patch multiple workstations like you would in an environment where the app is installed on multiple workstations).  You can also (using remote boot type setups) run with diskless workstations if you want (similarly to how Workspace on Demand works) and have no local machine storage for anything other then a swap file, no local hard disk (other then for a swap file - improving both central management, site security, centralized site backup, etc).

Admittedly running Linux ports from a network share in this manner may not work within the FHS / YUM / RPM model.

I hope this provides a little insight into what I'm talking about with regards to running apps from a network share.  Thanks for your replies and the continued discussion!

Title: Re: RPM packager
Post by: aschn on 2011.09.07, 22:40:28
Quote from: Fahrvenugen on 2011.09.07, 17:12:59
Quote from: dmik on 2011.09.07, 14:00:39
Quote from: Fahrvenugen on 2011.09.07, 07:44:55
So yes, I do know what I'm talking about - moving applications from
one folder and / or drive letter to another, using drag and drop. And
yes, it does work for many OS/2 based applications.

I didn't say that this does not work. You probably don't remember, but
I said that this will only work for simple apps with no dependencies.
This is not the case for modern apps we provide. Even a trivial kdiff3
utility needs the Qt4 runtime. Packing the Qt4 runtime with each
application will increase its installed size by 40-50 MB even if the
application itself is 500 K. This is insane and this will create an
incredible mess of DLLs on your system.

So essentially from what you're saying this isn't all that different
from apps which use the OS/2 system DLL's, emx DLL's, the Libc dll,
etc. The apps will need to be able to see the libraries they use.

Fahrvenugen, as soon as an app stores a path that points to a file
object of the installation using an absolute pathname, your are lost
with drag and drop. The applies for almost all apps. IBM never
managed to finish the idea behind it. Some details:

Usually installed OS/2 (not ported) apps write their installation
path to OS2.INI. If you move the installation files, the program
objects were synchronized, but the entry in OS2.INI not. Apps have
to be specially prepared to handle that situation. E.g. even EPM
contains code to handle it, but it's full of bugs.

Please let us end the discussion about drag-and-drop ability, even
OS/2 apps don't know how to handle that.

--
Andreas Schnellbacher
Title: Re: RPM packager
Post by: Pete on 2011.09.08, 02:55:07
Hi Andreas

With regard to the drag'n'drop: some os/2 apps do write an install path to os2.ini; a lot do not.

However, even apps that write this path data in os2.ini do not seem to have problems - os2.ini seems to get updated with the new path when the app gets moved.

Regards

Pete
Title: Re: RPM packager
Post by: dmik on 2011.09.08, 04:50:49
lewhoo, about hard disks. Given that in order to install all software avaliable for OS/2 you will barely need a partition more than 10G (remember, we don't calculate your data, it's separate), even five years old notebooks have space for 10 eCS installations. So this argument has nothing behind it. As for multiple eCS installs, RPM does everything for you, so it makes no problems to simply have everything installed everywhere and only share data. Regarding your 3rd point, you don't understand one simple thing -- the cost of maintaining software so that you can toss it around in any possible way and it still works is zillion times higher then hard disk space costs. Wake up! Nobody will do it. It makes no sense in 2011.

I don't undertsand why moving to the WPS level is not a solution for you. You don't present arguments. "It's a downgrade" and "other software works" are not arguments. "I don't feel okay with that" is not an argument either -- it could be if we were trying to sell a million egg slicers to houesewives. But this is just not the case.

The backup of user data is to be done the usual way. Copy/zip/whatever your %HOME% folder to a safe location.

lwriemen, there is no nothing or all approach. ZIP is not nothing. Yes, you may use logical volumes to seamlessly increase the hard disk size, this is entirely up to you (end-user). The concept of RPM is not fully clear to you -- its full potential opens up when it manages everything. But don't worry that much, it will not happen too soon. Re FHS, see the previous post.


Fahrvenugen, There is a difference from apps using OS/2 DLLs -- OS/2 DLLs are present on the system. Qt4 DLLs are not. Also take into account what Andreas said, he made a good point about OS2.INI which I didn't mention.

I understood your network share usage pattern correctly. I know all the stuff you mentioned, I did things like WSoD myself (I worked in a school as a sysadmin in the past; pupils are very aggressive users so I learned lots of stuff from there). While you may actually make this solution work in FHS pretty well (by redirecting /usr and /etc to a network share), this doesn't give you many benefits compared to the native RPM way where you may easily get the same "automated distribution" effect by installing/updating the necessary software from the user's logon script with a few simple yum commands. However, RPM, in turn, will give you a lot of benefit here because running the software from the hard disk is simply much faster than from a network share.

Pete, what you said about changing paths in OS2.INI when applications are dragged to different folders, is a fairy tale.
Title: Re: RPM packager
Post by: Andi on 2011.09.11, 13:19:52
Just installed rpm/yum. As my applications usually are on P: I set unixroot=P: (wpi installer does not like slash or backslash after drive so be aware to set your unixroot without that). After installing yum there are 5 new directories at P:. bin, etc, tmp, usr, var. Don't understand why tmp was created cause I've %TMP%=T:\TEMP anyway. etc seems to be not necessary too cause there is %ETC%=D:\MPTN\ETC anyway. Moreover I think etc and var should be better on my data volume on E:\ and not on the applications volume. But leave it for now. Have to look if this can be corrected later. All in all it's about 180MB in 5 directories. Currently on P: there are about 14GB and more than 260 directories at root level. So I've no problem with that few additional MBs and dirs.

Here we go, let's install some applications. But yum list leads to -
{0}[d:\] yum list
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   dlopen rc=2 extra=PYTHON25

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.6.5 (r265:79063, Jan  4 2011, 13:06:36)
[GCC 4.4.4]

If you cannot solve this problem yourself, please go to
the yum faq at:
  http://yum.baseurl.org/wiki/Faq

Although the error message points to the problem, for a normal user without online chat with Dimitry ;) it maybe not that easy to resolve this. I miss the statement in the readme that you should remove all references to python like SET PYTHONHOME=p:/python25 in your config.sys prior to installing rpm/yum. After that it works as designed. Of course this may influence all your current python applications cause rpm/yum installs a newer python version. But for me I'm sure the newer python is compatible with all my python code. So no real problem here for me.

A few days later I wanted to install something new with yum. yum list available |more gives a list of available packages. Hint, it's more comfortable to read if you set more than 80 columns before (f.i. mode co81,99). Of course you can redirect the list to a file if you prefer. yum install exceptq starts to install exceptq. A long list of packages for update appears and yum asked for downloading 27MB. After accepted initially I interrupted the update process. I thought there must be something wrong cause exceptq can't be 27MB in size. Checking some packages I see there were a lot of changes in the repository. Updates of ash, coreutils... and so one. Seems there were some developers rather busy. So yum/rpm is correct in updating this packages. Although I do not understand why this all is necessary for exceptq, I trust in the packager of excepq knowing it better than me. And I understand from the developers point of view it's much easier to support a user when you know the user have installed the correct/latest utilities which may influence your software. So it makes sense to keep some core utilities at a current level. Remember on other operating systems it's common practice since years to force users to install the latest service packs before the get any support or before he can install some new software. This is not to bother users but it became impossible to support users with complex applications without keeping their environment up to date. I know especially eCS users do not like to give away even a small piece of control over there system. But we have to accept this when we want to use complex ported software I think. So take it or leave it. No problem when someone wants to stay f.i. with Warp 4. But do not bash the people who work on eCS and can not support your W4 system then. Same here. So firing up again yum install exceptq and yes, rpm is smart enough to download only the missing files from the previously interrupted installation. This is also true when the network connection to the rpm server fails during an install attempt which was the case here too. rpm takes care of that and knows if it have to download something or not. Very smart. I start to like it :)

Of course there are some unaesthetic aspects with this new rpm way for updating your system. F.i. yum install unzip installs the (nearly) same unzip version I still had on my system just in another directory. But he, even after a plain new eCS install I had 2 unzip.exe versions on my system.

[d:\] which -as unzip.exe
   1: 08/27/11 11:38:34     82676  p:/usr/bin/unzip.exe
   2: 05/30/10 10:37:14    136647  p:/util/unzip.exe
   3: 05/23/08 15:40:08    147507  d:/ecs/bin/unzip.exe

Now I've 3 and I can safely delete the older 2 cause I'm sure rpm takes care of the latest one with all its dependencies. I do not need to take care by myself if the right one is in the PATH and the correct libc is in libpath cause rpm set the path so that it's version will taken by default and checks the dependency. And as long as the rpm repository is kept up to date it's very easy to keep my system up to date too. After playing around a little bit with yum/rpm I'm think I will like it. Boys nice job what you've done. A big THANK YOU. Thinking about the troubles I had with various software, setting the environment correctly and manually check the dependencies, I know there's a big chance for rpm to makes these mess a little easier to handle in the future. Please keep the rpm repository up to date and fill it with new applications.

What's left to do for me is to check how to handle a local repository. I want to download the same software only once for all eCS systems I have. Another thing is to check how rpm handles the situation that my application volume usually on P: is the app volume for different eCS installations on the same system. Does rpm know that there's nothing to install beside the config.sys entries when booting from the maintenance partition? Will check as soon as time permits.

Again, thank you for doing all the great work to keep eCS alive. And if you think it's easier to port, distribute and support software the rpm/yum way, and I'm sure it is, just keep on going that track. And to all participants at this thread, please try to keep emotions low and do not attack personally. This should be a discussion about pro and cons of a way how to make new apps available to the community. Not about personal reservations or language barriers....

Regards,
Andreas

Btw, in the readme you can see how much ahead of time the rpm/yum porters are :)
HISTORY
1.3 - 13 Jan 2012



Title: Re: RPM packager
Post by: CDRWSel on 2011.09.11, 17:10:23
Losing control = external control => possible system intrusion, malware, trojan installation etc...
This is a real danger having all updates from one depository because as soon a virus is present, all users will get it too.
Some older programs using older dll build fail etc... No way to control and find out what's going wrong then.

As you wrote, many updates occured while you didn't request them !
If you like have a fully open system to every body on the world, this may be a good option.
Title: Re: RPM packager
Post by: Andi on 2011.09.12, 09:36:46
QuoteLosing control = external control => ...
You never had much control over your system. In fact you trusted IBM and its subcontractors that they built components which protects you. They hardly made any source code available so you even can not check by yourself.
Quote...all users will get it too...
Only those users who decide to install this software. Same as with every other peace of software. If f.i. someone implements a back-door in the new file open dialog or in clamav and you decide to install it, or it is included in the next eCS3.x, you get it too. Of course you can choose not to install new eCS, nor clamav or new file open dialog. The same is true with rpm packed software. Oh no, not the same, usually rpm bundled stuff is open source as far as I can see. So chances are good it's even more save than eCS or file open dialog....

It's all a matter of trust and to whom you trust. If you trust the >5 years old IBM supplied tcpip stack or the patched version from Steven or not is up to you. And you choose if you want to install or not.

QuoteSome older programs using older dll build fail etc...
Till now I did not find such a program. Examples please. In fact it would be the fault of the dll builder if he supplies a new dll with the same name which is not backward compatible. I suppose you fear the problems from win swapping over to eCS. As long as there are no real examples it's not worth to discuss this special point any further.

QuoteAs you wrote, many updates occured while you didn't request them !
But I also wrote yum/rpm is correct in updating this packages. If I wouldn't have wanted the new coreutils update, I didn't have allowed it. Simply a matter of choices. If you don't like it, do not install.

QuoteIf you like have a fully open system to every body on the world, this may be a good option.
Better option then would be using Windoze.
Title: Re: RPM packager
Post by: dmik on 2011.09.12, 13:57:53
Andi, thank you for the detailed feedback. You are welcome -)

The problem with PYTHONHOME you mentioned is already fixed in the new version of the os2-base package (this statement is removed from config.sys if present), so one should not face this issue any more.

Maintaining the local RPM repository is fairly easy:

1. Install the createrepo package.
2. Add a file local.repo to /etc/yum/repos.d/ that contains:
     [local]
     name=My local repo
     baseurl=file://<path_to_repo>
     enabled=1
3. Put your .rpm files to <path_to_repo>.
4. Execute
     sh createrepo <path_to_repo>

I'm not sure if RPM tools will understand <path_to_repo> if it contains the drive specification, you will probably have to add a kLIBC pathrewriter entry that maps e.g. /drives/p to your P: drive and then baseurl will become "file:///drives/p/temp/build/RPMS" and for createrepo you will give "/drives/p/temp/build/RPMS".

P.S. I may sound tough sometimes, but I try to only operate on facts so there is nothing personal in my words (unless I explicitly state that), sorry if somebody got it wrong.
Title: Re: RPM packager
Post by: Andi on 2011.09.13, 21:44:41
Thanks for you description Dimitry.
4. have  to be started from /usr/bin I guess or as I did with full path specified
[p:\] sh "P:\usr\bin\createrepo" <path_to_repo>

Now I've to find out how to expose my local repository in my lan. Best option would be when my local repository can be synced with netlabs-rel and then local clients can connect to my local repository. I think this is a common scenario so guess this would be possible. It's not that urgent now so maybe look into it another time.
Title: Re: RPM packager
Post by: minou on 2011.09.16, 03:09:53
A comment about windows which miturbide mentioned. Actually Microsoft is looking into implementing something like RPM for windows. It will be a Microsoft rewrite so they say.
They found out that RPM is the best packaging system so far. Debian users will get upset when they read that but this is life.
One serious issue I had with a customer with windows what that our parent company who makes the CAN device used had a different dll with the same name, the installer didn't complain and nothing worked.
With a RPM style installer the customer would have been made aware that the version was older than the one he needed. If I know that a program will not run with an older library I like the fact that I can have the installer flag that stuff. In this particular case that could have saved us thousands of dollars.
One great advantage of RPM is the ease to recreate the packages. Right now I have on my system Scientific Linux, Centos, Gentoo, Fedora 15. I used to have Fedora 13 and 14, Mandriva 2009, Mandriva 210 plus SuSE but that hard disk died. When I wanted to port a program to another system I just had to recomplile in most cases using rpmbuild -ba xxxx.spec. In a few cases I had to do some changes in the spec files, Mandriva has the nasty habit of using Mandriva only macros. That is not a problem once you are familiar with those macros.
If all you do on your OS/2 system is use binaries, any packaging system used should be irrelevant as long as the program runs fine.
To the question about the graphic interface, yumex which I use on all my Redhat style Linux is simple and all click click like most of you are used to. Yumex is just a graphic wrapper for the command line Yum.
It works very well and should be simple to port to OS/2.

Atmel has decided to go Windows only for the AVR32. This pissed me off greatly. So far I found some way around. I have not documented it yet, it involves using some older version of the programmer. I got it to work on Scientific Linux. I have a feeling that sooner or later no one will be able to use the programmer as there is no plan to update the linux version for now if I am to believe the message from my contact at Atmel.
The new programmer doesn't work if your system is new. Despite the good contacts I have with Atmel I was not able to get source code for gdbproxy so I will have to find a way to program by writing my own once I get the documentation on JTAGICE mkII debugging interface. One way would be to get the driver from Windows to work on OS/2, is that possible? or is Odin only for regular binaries.
I was able to recompile all the develeopment package for the AVR32 UC3 series. I did the same with the PIC32 by the way.
My goal in the next few months is to port the AVR32 stuff first to OS/2 (Actually eComStation 2.1). When I get my debugger working I will do the PIC32.
Once that is done ARM Cortex M3 is next ...

Title: Re: RPM packager
Post by: Blonde Guy on 2011.10.07, 17:00:11
Has anyone used the python interface to YUM?

What would be cool is a REXX encapsulation of the YUM module interface. Quite a few people have REXX experience on OS/2, as compared to very few have Python. REXX support is built-in. I suppose once YUM is installed, Python is included, but I don't think anyone has made OS/2 INF files for Python yet.

Also, are there now Python modules to read/write OS/2 INI files or create WPS objects?
Title: Re: RPM packager
Post by: Andreas Kohl on 2011.10.09, 01:03:59
YUM is a collection of python scripts. Unfortunately Python under OS/2 is not very friendly and usable. So, why not simply using RPM commands from REXX procedures.
Title: Re: RPM packager
Post by: jep on 2011.10.09, 19:45:44
Hello,

I'd propose that you'd provide RPM as .dlls with rexx entries built in as well.

That goes for many VIO/CLI apps... rexx wrapper one can use, as I find it excellent at handling parsing of parameters, user interaction and provide a forgiving interface.

//Jan-Erik
Title: Re: RPM packager
Post by: guzzi on 2011.10.31, 23:26:14
My 2 cents worth:

-Rant on-
Although I do not like the 'chuck everything in the same directory' approach of the linux file structure, there are major advantages. I am not a programmer/developer, but I do understand some of the problems they encounter, especially when porting from Linux, which is defacto the major source of 'new' applications for OS/2. Instead of focussing on the downside of using the linux file structure, we should look at the advantages. As an example, Ko Myung Hung's VLC port. It uses a linux structure, probably because it would be a lot more work to port it in an os/2 way, if at all possible. I have taken the zip and moved it to the rpm/yum created tree, deleted the config.sys path entry that was needed according to the docs, and it works. To keep everything separate would mean the path/libpath statements in config.sys will simply grow too large. This problem is at least 10 years old.... and disappears using the linux structure. As for rpm/yum, it does have problems. It wouldn't install properly on my system and I had to use rpm with a force flag to install some libraries that weren't properly installed by the bootstrap. Still, it works now. ClamAV doesn't work, don't know if it's an installation problem or a bug in the port. A GUI will come for rpm/yum, which will make it easier to use, but even from the command line it's not that difficult, especially not for those who are used to 'put everything where they want it' like me. We fiddle around a lot with stuff anyway, and therefore are familiar with how things work. Let's not forget that most OS/2 development is done in free time, unpaid. Even the paid development will most likely pay a lot less then say, what the guy I know at Google makes in a month.... Beggars can't be choosers, and we are beggars with respect to development. Let's be glad there are still people willing to put a lot of time and effort in making things work. Dima's statement about 'developer knows best' may be a little crass in formulation, the fact is that coding wise, he is entirely right. Only those who port programs, know how the stuff works and is the most easily ported.
-rant off-
Title: Re: RPM packager
Post by: CDRWSel on 2011.11.01, 00:15:26
Hi guzzi,

I have no RPM/YUM and use VLC payer and didn't add any entries into config.sys !

RPM/YUM and other ported tools aren't free and you pay it under eCS licence and if the developpers would realy work for free like I do, I think that eCs could be sold at a lower price and many more people could buy it !

Netlabs developpers do not work "gratis".
Title: Re: RPM packager
Post by: rudi on 2011.11.01, 08:12:44
Quote from: CDRWSel on 2011.11.01, 00:15:26
RPM/YUM and other ported tools aren't free and you pay it under eCS licence and if the developpers would realy work for free like I do, I think that eCs could be sold at a lower price and many more people could buy it !

Netlabs developpers do not work "gratis".

I think you have a completely wrong idea about what Netlabs is. Primary, it's a site that host projects. Most of them have nothing to do with Mensys. There are three kinds of projects: Private, sponsored and free. Private projects are those, for which a company (like Mensys) pays for. That is for example ACPI and USB. The source code for those is usually not publically available. Then there are sponsored projects. These include Qt and Java. Projects of that kind are considered to be too large/complex to be handled by programmers in their spare time. Thus at least the lead programmer (like Dmik, who BTW is one of the most capable programmers I know) is payed to dedicate a specific amount of time to the project. Individuals as well as companies (like Mensys) are free to sponsor something they consider as useful or important. But that doesn't usually mean that they decide the direction in which the project will progress. AFAIK, Mensys has not indicated any interest in RPM/YUM. So this falls in the 3rd category: it's a free project and nobody is paying for it "under eCS licence".

Also note, that there are actually people (like myself) who from time to time contribute to sponsored or even private projects. Gratis.

Title: Re: RPM packager
Post by: CDRWSel on 2011.11.01, 11:25:30
Hello Rudy,

Thanks for your clarification.
Best regards
Title: Re: RPM packager
Post by: miturbide on 2011.11.07, 04:02:42
Fedora To Simplify Filesystem Hierarchy, Move Everything to /usr (http://"http://www.osnews.com/story/25289/Fedora_To_Simplify_Filesystem_Hierarchy_Move_Everything_to_usr")

"Good news from the Linux world. Fedora has announced its intention to drastically alter the file system layout of its Linux distribution. The plan's been out for a while.... The gist is to move all binaries to /usr/bin, and all libraries to /usr/lib and /user/lib64."

"Splitting things up complicates stuff. If you want to keep things separate you really need a good reason for that. We should always focus on simplifying things," Red Hat's Lennart Poettering wrote, "And merging things into /usr does just that: it drastically simplifies the complexities we have collected over 30+ years of Unix heritage."


Seems that FHS as it is right now it is not good enought for some Linux users ;P
Title: Re: RPM packager
Post by: DougB on 2011.11.07, 05:40:30
QuoteSeems that FHS as it is right now it is not good enought for some Linux users

It appears that they are attempting to turn Linux into windows. Put it all in one place, so nobody can find anything. It is a sure way to increase the number of dead files, that nobody knows what they are for.

FWIW, I installed RPM/YUM on my test machine, with a new eCS 2.1 install. That part seems to have gone okay. I then installed ClamAV, with the intention to repackage the latest as a WPI file. Not much hope of that, since bits and pieces are all over the \usr directory structure. RPM/YUM also forgot to build icons for ClamAV. There is one text file icon, and that is it. Now, I suppose I am expected to track down where all of the programs are, and build my own icons. Yeah, right...

I am NOT impressed.