[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package System specification

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

Exactly!  But you don't have that now, so why do you care if that is missing 
in the future?  My point is to also prove that you're missing this info now 
and you probably need to find a way to get it anyway.  Move to a system that 
provides it...RPM or something else.  If something else, my bet is that we can 
make it work fine with RPM, too.  .deb already does.  Hopefully in the 
not-too-distant future RPM and .deb package files will be the same format 

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

Ding!  We have a winner.  :-)  My point, and that of most folks here working 
on the LSB seems to be that vendors *need* that level of functionality.  Catch 
up and be able to provide it, or you won't be a target for the vendor at all 

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

Or an equivalent.  And vendors are going to require at least an equivalent.  


  Donnie Barnes    http://www.donniebarnes.com    djb@redhat.com    "Bah."
   Challenge Diversity.  Ignore People.  Live Life.  Use Linux.  879. V. 
             "I love the smell of napalm in the morning."

Reply to: