Poll

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

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

Total Members Voted: 0

Author Topic: RPM packager  (Read 25068 times)

djcaetano

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: RPM packager
« Reply #60 on: 2011.08.31, 16: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

miturbide

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1154
    • View Profile
    • OS2World
Re: RPM packager
« Reply #61 on: 2011.08.31, 16: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.


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.


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


« Last Edit: 2011.08.31, 16:54:14 by miturbide »
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

dmik

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: RPM packager
« Reply #62 on: 2011.08.31, 18: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%).

Pete

  • Hero Member
  • *****
  • Posts: 865
    • View Profile
Re: RPM packager
« Reply #63 on: 2011.08.31, 18: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

Pete

  • Hero Member
  • *****
  • Posts: 865
    • View Profile
Re: RPM packager
« Reply #64 on: 2011.08.31, 19: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

ydario

  • Newbie
  • *
  • Posts: 22
    • View Profile
Re: RPM packager
« Reply #65 on: 2011.08.31, 19: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

djcaetano

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: RPM packager
« Reply #66 on: 2011.08.31, 20:26:34 »

  Hi Yuri,

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

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

Fahrvenugen

  • Full Member
  • ***
  • Posts: 203
    • View Profile
Re: RPM packager
« Reply #67 on: 2011.08.31, 22: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. 




Paul Smedley

  • Sr. Member
  • ****
  • Posts: 322
    • View Profile
Re: RPM packager
« Reply #68 on: 2011.08.31, 22:58:28 »
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%

DougB

  • Sr. Member
  • ****
  • Posts: 407
    • View Profile
Re: RPM packager
« Reply #69 on: 2011.08.31, 23:12:34 »
Quote
While 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...

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

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

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

You, and everybody else, need more developers.

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

dmik

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: RPM packager
« Reply #70 on: 2011.09.01, 02: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.
« Last Edit: 2011.09.01, 02:46:31 by dmik »

dmik

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: RPM packager
« Reply #71 on: 2011.09.01, 02: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.

miturbide

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1154
    • View Profile
    • OS2World
Re: RPM packager
« Reply #72 on: 2011.09.01, 15: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.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

melf

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 606
    • View Profile
Re: RPM packager
« Reply #73 on: 2011.09.01, 17: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.
/Mikael

dmik

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: RPM packager
« Reply #74 on: 2011.09.01, 17: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.