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

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

On Mon, Jul 02, 2001 at 10:37:26PM -0600, Jason Gunthorpe wrote:
> They don't appear to be mentioned in Maximum RPM per say, however..
> 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.

Part of the problem here is that the RPM maintainers wasn't very
careful, especially in the early days of RPM development, to
appropriately flag format changes as they were made.  (And most of
those format changes were documented except in the source code).

> I reviewed it, I knew, I brought it and lots of other issues up. That
> resulted in lsb-taskforces 1 through 3 being formed, and then nothing was
> accomplished. That was in December. 6 months later the spec was published 
> unchanged. What went wrong?

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
at the mail archives so I don't have enough data to form a fair
opinion.  (Nor is it clear that this would be especially fruitful).

What happened to me was that just before the LSB 1.0 was released, I
noticed some specific problems with the chapter 13, and did some last
minute fixups that fixed the namespace problems that it had, and I
eliminated references to "RPM v3 format", since that was clearly
ill-defined, and replaced it with "what is defined in the appendix to
Maximum RPM".

I think the problem was that none of the people who had been
participating on the LSB taskforce were involved with the actual LSB
standards writing effort, and so no one summarized the discussions on
the taskforce mailing list or provided text to the people who actually
had commit privs on the LSB CVS tree.  If someone had simply posted a
message to the LSB-spec mailing list that the LSB-taskforce1 efforts
weren't converging on a solution, that might have brought this problem
to our attention sooner, but as it was, I think it was simply a
problem of there not being a good liason between packaging group and
the people actually writing the standard.

As far as simply deleting chapter 13 from the specification, that
possibility did cross my mind, and I did think for a while that it
might have been the best choice.  But others argued that having
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
the package later, upgrade the package), in a way that would be better
than just simply telling ISV's that the only way they could package
LSB software for Linux was via binary tarballs.  And, those arguments
carried a lot of weight.

						- Ted

Reply to: