Re: Package System specification
>> My point was that package
>> converters will never work as well as the real program for the original
>> package.
>
>And my point is that you're wrong, as far as systems like Slackware are
>concerned. RPMS work just as well as a tarball. They are a superset of the
>functionality provided by a tarball. If all you use is a tarball based
>package system, installing the files contained in an RPM will work just as
>dang well.
Yes I know, but converting to a tarball loses dependencies and any other
special RPM data that the vendor may make use of.
>Your point seems to point to situations like .deb vs .rpm, but the .deb folks
>don't seem to think this is an issue. I'm saying that *you* shouldn't think
>it is an issue, either. I could perhaps see a point if you were from .deb
>land and were worried, but as a .tar.gz guy, your points don't make sense.
It is an issue since dumping an RPM to a .tar.gz doesn't give you ALL of the
RPM data, only the files.
>> I'm not against dependencies If there is a dependency, it should be the LSB.
>> Written correctly, that could work and commercial vendors would have no problems
>> porting or writing software for an LSB-compliant system. Anything that isn't
>> in the specification would need to be provided by that vendor, as well as an
>> installation system (it's not really a big deal...look at Star Office and
>> Netscape).
>
>Dependencies will still always be necessary in the current form as well as
>part of the LSB. The LSB won't ever standardize everything, and I would
>expect complex systems like Oracle to want to use the RPM (or similar)
>mechanism for their own applications to make sure things of *theirs* that need
>to be there are there. Some vendors may also want to rely on open source
>libraries that aren't spec'ed by the LSB that many distributions *do* ship.
>They'll want to use them if they are there, and provide them in case they
>aren't. But the last thing they want to do is overwrite them unnecessarily
>since that could break things. Have you ever seen the mess that is the world
>of .dll's in Windows land? Every single game on the planet nicely provides
>its own DirectX drivers and installs them no matter if you have a newer one or
>not most of the time, which can break installed things. This is avoidable and
>we should do it if we have the ability. RPM has that ability.
OK, now all of that sounds nice, but won't work unless you are using an RPM
system with an RPM database and so forth.
David Cantrell | david@slackware.com
| Slackware Linux Project
Reply to: