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 29228 times)

CDRWSel

  • Sr. Member
  • ****
  • Posts: 420
    • View Profile
Re: RPM packager
« Reply #135 on: 2011.09.11, 16: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.

Andi

  • Sr. Member
  • ****
  • Posts: 264
    • View Profile
Re: RPM packager
« Reply #136 on: 2011.09.12, 08:36:46 »
Quote
Losing 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.

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

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

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

dmik

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

Andi

  • Sr. Member
  • ****
  • Posts: 264
    • View Profile
Re: RPM packager
« Reply #138 on: 2011.09.13, 20: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.

minou

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


Blonde Guy

  • Sr. Member
  • ****
  • Posts: 283
    • View Profile
    • Blonde Guy
Re: RPM packager
« Reply #140 on: 2011.10.07, 16: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?
Expert Consulting for OS/2 and eComStation

Andreas Kohl

  • Newbie
  • *
  • Posts: 5
  • Operate at a higher level
    • View Profile
Re: RPM packager
« Reply #141 on: 2011.10.09, 00: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.

jep

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 421
    • View Profile
Re: RPM packager
« Reply #142 on: 2011.10.09, 18: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

guzzi

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: RPM packager
« Reply #143 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-

CDRWSel

  • Sr. Member
  • ****
  • Posts: 420
    • View Profile
Re: RPM packager
« Reply #144 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".

rudi

  • Full Member
  • ***
  • Posts: 116
    • View Profile
Re: RPM packager
« Reply #145 on: 2011.11.01, 08:12:44 »
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.

« Last Edit: 2011.11.01, 08:19:15 by rudi »

CDRWSel

  • Sr. Member
  • ****
  • Posts: 420
    • View Profile
Re: RPM packager
« Reply #146 on: 2011.11.01, 11:25:30 »
Hello Rudy,

Thanks for your clarification.
Best regards

miturbide

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

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

DougB

  • Sr. Member
  • ****
  • Posts: 407
    • View Profile
Re: RPM packager
« Reply #148 on: 2011.11.07, 05:40:30 »
Quote
Seems 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.