• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

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

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

Main Menu

RPM/YUM !

Started by CDRWSel, 2011.01.02, 17:45:00

Previous topic - Next topic

IBManners

All I wanted to do today was upgrade ClamAV, not have a program screw with my build environment after sucking more than 40M over my DSL connection, software is not ment to be this hard, and I am happy the way my directory structures are laid out for ME, and have evolved over the past 20 or more years. UNIX directory structures are also not all alike though they do often have a common base.

RPM/YUM maybe fine but I do not like being told it has to be done 'this way', or 'that way', if I did I'd install windows. I don't need all the crap it wants to install on my server.

I am also not prepared to put something like RPM/YUM on my server just to install or upgrade a program. If I am forced to do it this way then I might as well give up on OS/2 and simply stick with AIX or move to a linux distro. OS/2 makes a lean mean machine but when you start adding things like this to it, its a worry.

I'm not saying that RPM/YUM has no place on OS/2 or eComStation, I'm simply saying its not for me, at least not in its current form. I understand were I want things, and why. I do things for a reason, my paths are streamlined, and I would like to maintain my choice to do things the way I like to.

Many moons ago I used RPM and I have no problems with the RPM program itself as I could simply use unrpm to extract files when I had no need to run the entire install, and it was small and fast. RPM/YUM needs a lot more work, the bootstrap program also needs a lot more work, get rid of the bloat.

I can understand the intent behind RPM/YUM, and I can see the need for it for certain categories of users but at this point in time it has taken my choice away, and created something that is simply to hard. Is it a case of pushing it out to early ?  I don't know, only Yuri and others can answer that.

Warpin I can live with simply because its small, and on the odd occasion I've wanted to I can unwarp an install file to a directory. Or in the past I could simply install ClamAV to my local computer and xcopy the structure across the network to my server with a clamav restart and its off and running again.

Maybe its me, I've been in this industry now for 31 years so obviously I'm to hands on.

Yuri, I'm not having a go at you on a personal level, just on a software level, so please don't let any criticism stop you from taking RPM/YUM in the direction you wish to take it BUT please don't lock people into it before its ready for prime time.

Cheers
IBM
I am the computer, it is me.

lewhoo

It seems, that the problem with RPM/YUM comes to a general problem of... "power user". OS/2 has always served best "power users". Linux for a long time was a thing mostly for "admins", while windows mostly for "users". Now we have rpm/yum, which is mainly for "users" - invoke and do not care where the thing is installed, what it really does etc. If one wants to gain any control, he has to be an "admin" - dig deep into command line options, etc. No place for "power user" - I want to decide what and where, but I don't want to make a PhD on the command line options of the package. That's the general tendency I see among different linux distributions - either make something for a very dumb "user" or something for "admin", nothing for "power user".

I wonder if rpm/yum porters would extend the port to fulfill demands of common-to-OS/2 "power users"? Or, are they willing to?

CDRWSel

Hi!

After doing a fresh eCS install, I could give more test on this RPM/YUM tool !
(of course, I install older ClamAV (WPI and my GUI first) 

The full installed RPM/YUM package requires 66MiB on the disk !
I start then the CLAMAV install !

It didn't check I already have it installed under my prefered directory and it installed it using UNIX/LINUX rules !
Main part goes into  :\usr\...   ( I do not know where due there is no installation details with path used for each product part and I find some pats of the program using a dir name /s/p ). Some other parts goes under .\etc\ ! and I found that the signature files where placed under .\var\... path

I remember the date where eCS rules was decided about programs to be installed under PROGRAMS by default
An easy way to have all files under a same program path. Now, despite the program to install (with this tool):

  • all exe files are going into .\usr\bin
  • all dll are going into .\usr\lib
  • Other files are going into a created directory under .\var\..
  • Other files are going into .\etc\..

What to think !
It looks to go to a full eCS redesign and supress of easy to use parts.

I tried to make my GUI work with the new ClamAV but I have to make lot of changes into the code. I wrote it to make me pleasure and to give all eCS user a friendly GUI but now, Be forced to re-write the code due to changes to always use new complicated path structure (lunix like) and use of unfriendly tool doesn't give me any pleasure and a lot of work to adapt my GUI (Do you know what ? ClamAV windows installation tools using one above build level 0.96.5 as eCS build level always uses easy self installation/update tool and you can install it where you want). For eCS, it was told that it isn't no more possible to do due ClamAV requirements !

I'll try to check if I could make a WPI using all parts of this installed build...

:'( 

DougB

QuoteFrom the other side WarpIn misses unattended install options using a command line,

Well, no it doesn't. A good part of the eCS install is done, automatically, using WarpIn. The instructions are in the Programmer's guide. True, it could be easier, but it is not really all that complicated, or useful.

QuoteAll I wanted to do today was upgrade ClamAV,

That was all that I wanted to do too, when I first stumbled across RPM/YUM. Sorry, but it didn't install ClamAV, all it did was add a big mess to my disk drive (and, yes, I did figure out how to keep it off of my boot drive, fortunately). ClamAV itself did not get installed properly, and there was no indication, anywhere, that any icons were built for it. So, I am still using the older ClamAV, that took me seconds to install, using WarpIn. This is definitely not an improvement, so far, and I don't see any way to fix the problem (not that I have tried too hard).

QuoteIt seems, that the problem with RPM/YUM comes to a general problem of... "power user".

I don't agree with that statement. I have also seen that statement used in relation to WarpIn, but it isn't really true there either. WarpIn is, currently, easier to work around, because it has the tools to extract the files, if a user wishes to do it that way. The main "problem" with WarpIn, is caused by those who package the programs. In a lot of cases, the packaging forces artificial restrictions on the user (which "power users" dislike). Of course, most of the time, that is done to prevent users from screwing it up, and to make trouble shooting easier. The other big complaint is about a user already having a package installed (LIBC063 for example), but not by WarpIn, so WarpIn will complain that it is missing, and refuse to do the install. The obvious answer is to simply install the "missing" package, using WarpIn, however, there is another answer as used by the PMMail installer, to simply look to see if the file exists in the libpath, warn the user if it is missing, but still let them install the package. WarpIn has a LOT of flexibility, but the packager really does need to think about what they are doing. From what I have seen of RPM/YUM, it will be a case of "do it their way, or don't do it at all". To be fair, if they are going to track every little program that gets installed, that is the way they need to do it, short of developing a program that probably wouldn't fit on a 250 GB disk. I think the main problem with RPM/YUM, is that it is meant to macro manage the whole system. The main problem with WarpIn, is that it is meant to macro manage individual programs.  The main problem with all of them, is that "power users" like to micro manage their systems. The average OS/2 user is not a "power user" (even though some like to think they are), so they do like a little guidance, which is more than adequately done by WarpIn. On the other hand, the average OS/2 user is not a beginner, and they do have some idea about how to manage their own system. RPM/YUM seems to be geared toward doing it all, in a specific manner. It also seems to just install things that it seems to think a user needs (perhaps they do, but it should be their choice, AND, they should be told what is happening).

This is not windows, and it is not Linux. It is OS/2, and I don't see any reason to force a set of Linux rules on the user, even if they are using some Linux origin programs (most of which are "interesting", but not necessarily useful). Drivers, and basic system components, are a different story, and they really should be put into an appropriate place, but WarpIn can do that too.

As I noted earlier, I intend to install RPM/YUM on a test (perhaps virtual) machine (if the disk is big enough), and I will use that to download packages. I will then either repackage them as WarpIn archives, for distribution to my other systems, or I will simply copy the files, as appropriate. If it ever becomes apparent, that RPM/YUM really is a superior solution, I may put it onto my other systems, but, from what I have seen, so far, that will probably never happen in my lifetime.

I do find it very interesting, that RPM/YUM is being installed by WarpIn. That has to tell you something.

CDRWSel

#34
One more update to complete my previous note:

* No Clamd.exe into 0.96.4 build !
* Only clamscan usable then !
* Tried it using line command but it crashed on several kind of files like those of OpenOffice or Jar or ZIP, Jisp while some other files are correctly scanned.

I checked what could it make force to use RPM/YUM ?
After doc review nothing ! or May be if you plan use the optional JIT unit test for which
Python (version 2.5.4 or newer) is needed but this one can be installed out of ClamAV
What else ?

QuoteI do find it very interesting, that RPM/YUM is being installed by WarpIn. That has to tell you something

The warpin package doesn't install RPM/YUM, it just install needed RPM/YUM process to download and install full operational RPM/YUM. Once installed, it uses 66MiB disk space
There is no possibility to uninstall RPM/YUM with warpin oncy RPM/YUM is fully installed.

David McKenna

 One thing I found about this RPM/YUM install: it does not set any SET PYTHON statements in the CONFIG.SYS. If you delete the bootstrap files after installing YUM (as recommended), then YUM will not work from the command line. I added:

SET PYTHONHOME=C:\usr\lib\python2.6
SET PYTHONPATH=C:\usr\lib\python2.6;C:\usr\share\yum-cli;C:\usr\lib\python2.6\lib-dynload;C:\usr\lib\python2.6\site-packages

  to my CONFIG.SYS and now I can type things like YUM LIST on the command line and it actually works...


HTH


CDRWSel

#36
May be you'll have to manually updated python path at next release !

Note: Despite you'll have Python installed under programs during a standalone installation, RPM/YUM installs it again...   (My SDD doesn't like this tool and thanks burning "SSD" quicker as it should)

Now, a full bootable implemented EXT filesystem is missing under eCS........


Just to give you an idea !
See attached YUM LIST output
note; each issued command took a long time and use lot of CPU time before getting answer back !

All listed produts have they EXE under a same path %UNIXROOT%\usr\bin
same is true for all DLLs which are under %UNIXROOT%\usr\lib
Think having all product mixed into same directories ! (what a regression)


One of the main OS/2 advantage which was to easy move one installed application from under a path to an other path seems no more possible with the use of a single "move" selected appl folder to new destination...   :'(

I'm uninstalling it now due I have no more space on my disk and some application are now duplicated due full uncompatibility with warpin entries.
Well, to uninstall, I have to remove manually all created directories like %UNIXROOT%\usr..., %UNIXROOT%etc..., %UNIXROOT%\tmp\yumbt... (it doesn't use config.sys TMP setting!), %UNIXROOT%var\cache etc...        

Cheers  
   



CDRWSel

Some news...

latest ported ClamAV always compiled using restricted @unixroot/ path and fully incompatible with older installation. New build could no more be installed anywhere under a private directory

I replaced all files under user clamav 0.96.2 dir using new files extracted from many rpm files. Trying to work with it, it complained not finding files under @unixroot/ path !  >:(
Don't try to find clamd.... It is into other server rpm files...    >:(

Of course, creating a WPI package out of these files for older installation compatibility has no sense due this ported build is author *blocked* to prevent any installation under a specific user directory while the previous 0.96.2 build had a unix structure like directories but all under the user installation path which do not need @unixroot ( oriented OS/2 friendly mode ).

Do you now what ? the Windows ClamAV 0.96.5 (more recent build ) has not this restriction and can be installed under any user path without use of @unixroot nor RPM !   :o

EugeneGorbunoff

Fresh idea: pack ClamAV GUI + ClamAV to .wpi, let's distribute it via eCo Market -- http://ecomstation.ru/ecomarket

More and more people start to use this service.

step 1: show me the icon of ClamAV
step 2: author, short description, homepage

IBManners

I have spend the last two evening screwing around with this, and I am totally fed up with this dogs breakfast of an idea.

And I agree with CDRWSel's findings, it is pure bloatware. If this is the way forward for eComStation, I give up now.

To Netlabs, I say to you, this is the biggest disaster I have seen you people do.

I will not be stuffing around having different structures on different harddisks, with X number of scripts to redo path entrys. What are you people thinking of ?

This is way to much harder than installing ClamAV under AIX of Linux !!

Why are you making this so hard ?
Is this someones strange idea to get every one that still use's OS/2 and eCS to dump it ?
I am the computer, it is me.

CDRWSel

Quote from: EugeneGorbunoff on 2011.01.23, 15:06:59
Fresh idea: pack ClamAV GUI + ClamAV to .wpi, let's distribute it via eCo Market -- http://ecomstation.ru/ecomarket

More and more people start to use this service.

step 1: show me the icon of ClamAV
step 2: author, short description, homepage

Hi Eugene,
I did the test creating a WPI (clone of 0.96.2 script) which wasn(t a problem but that the newer ported ClamAV was compiled without any respect of previous build path structure nor OS/2 rules...

The only interest to create a WPI is to make is work using same path and os/2 facilities as previous build and trying like this, the new ClamAV was build to never work...

Note: RPM/YUM and ClamAV have same porting author...

DougB

It looks to me, like somebody will have to reinvent the wheel, and do it right, since it seems that Yuri isn't interested in supporting ClamAV in a proper way any more. I sure hope that other important things don't get buggered up with RPM/YUM, but it does appear that netlabs has been conned into using that mess. FWIW, I don't need an antivirus program bad enough to bother using RPM/YUM to install it, however, it is still important to have some sort of AV program, so I guess the search is on again. What else is out there, that can be made to work with eCS?

Paul Smedley

btw look for unrpm.zip - not sure where I downloaded it from, but it can be used to extract an rpm to get the base files out - without installing rpm.

CDRWSel

Hi Paul,

No problem extracting rpm files !
The ClamAV was compiled to not work using private installation path as before...   >:(


IBManners

unrpm'ing the files is easy, getting what you then have is not  :'(

RPM/YUM also comes with its own set of GCC runtime libs and other files, this is what has been giving me headaches as well as the strict paths compiled into this build of ClamAV.

No matter what I've done, ClamAV will NOT run unless it is in the exact environment, and directory structure as YUM has setup. No ifs, no buts.  I cannot run it on my server, and as its a server (even if it wasn't) I'm not prepared to blow it away and start from scratch the way that someone else tells me it has to be done, just to run one program.

It maybe possible to modify paths etc with a hex editor but I don't have time for anymore tinkering at present, and its also something I don't want to have to do everytime I want to upgrade a program.

Are all other RPM/YUM installs going to be like this ?

Toe the party line comrades, otherwise run a different OS  ???
I am the computer, it is me.