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

Re: [users] Re: Time to fight for our beloved DEB format!



On Tue, 3 Jul 2001, Theodore Tso wrote:

> > You just said RPMv2, which is what Maximum RPM describes. But the appendix
> > linked from the LSB actually describes RPMv3.  
> 
> The confusion here seems to be caused by an ambiguity between the
> version of the RPM *format* which is V3, and the version of the RPM
> *implementation* which as of the writing of Maximum RPM was RPM v2.3.

Well, does it matter? The version 3 format is certainly capable of way
more than is documented in Maximum RPM. What's allowed? 

Maximum RPM is not enough by itself to implemement RPM package management,
so I'm really not sure what to do here. RPM file format 3 is capable of
file depends, but those aren't described in Maximum RPM, so is it valid or
not? There seem to be a bunch of other things, like versioning, and
detailed dependency semantics that just aren't really nailed down.

It's really a bad situation, but honestly the only people who care are us.
Everyone else uses the rpm program and rather by definition rpm works with
whatever it is the lsb has specified.

> I'm not sure what happened with LSB Taskforces.  There was apparently
> some problems with the task forces reaching consensus, and I have some
> private e-mail blaming some specific individuals, but I haven't looked

Consensus? I don't think we ever had a clear topic to build consensus
from! Supposidly the purpose was to build a LCD for use as chapter 13 in
version 1.0 of the spec. I got the furthest along such a document but
discussion *never* revolved around concrete things like actual
specifications.. 

In any event, the only hope to get this mess fixed is to have the
taskforce produce something, and fast. It seems to me that something
should be the restrictive document that chapter 13 was intended to be, 
but written as a specification.

> somethign which specified things in an exteremly restrictive way was
> still useful, since that meant that ISV's could package up their
> software in a way so that users could easily manage it (i.e., delete

I hold that opinion too, but I don't think the current spec is 'exteremly
restrictive' simply because it leaves far too much open, the maximum rpm
book is just too incomplete and vauge in some areas to be a formal spec.

Jason



Reply to: