Re: [users] Re: Time to fight for our beloved DEB format!
On Tue, Jul 03, 2001 at 12:45:11AM -0600, Jason Gunthorpe wrote:
>
> > 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?
The version 3 format is capable much of yes. That's because the
header uses a a type/length/value scheme. However, Maxmimum RPM also
has a listing of Header Tag listings, which was current as of version
2.3 of the RPM implementation. The intent was that is what's allowed,
and nothing else.
This does mean that some RPM features, such as versioned dependencies,
are left out. But because I decided that since Maxmimum RPM was the
closest thing to a documented format, it was easier to use it as a
more restrictive guide, and if later on the short-term packaging
taskforce wanted to be more liberal about what RPM tags were allowed,
it's always easier to loosen up a spec and allow more things than to
try to tighten it down later.
> 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.
Actually, other people *do* care about it. At least I care.... the
problem is that Red Hat has continued to add features, much like
Microsoft adds features to Microsoft Office documents. This provides
for backwards compatibility, but not necessarily for forwards
compatibility --- and not all RPM-based distributions are necessarily
using the latest bleeding-edge version of RPM.
So for the purposes of trying to assure compatibility, it's in fact
quite important that some kind of restriction is made about what kinds
of things are allowed in an RPM-subset that is guaranteed to work
across all distributions --- not just Red Hat 7.1.
> 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..
That was the goal which the short-term packaging taskforce was charged
with, yes. It sounds like the taskforce needed someone to act as a
facilitator, or at least someone to make sure things kept on track.
> 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.
It could be better, yes --- the main problem I see is that there isn't
a formal definition of what each of the RPM Header Tags means. Still,
it's the closest thing that we have to a formal specification.
A question I have is whether the best use of people's time and energy
would be tasked towards trying to do a full formal specification of
the RPM format, or whether time and energy would be better spent
towards trying to devise a new package format that everyone could
actually agree towards. If people think that this is impossible, and
the only thing we *can* do is a restricted RPM subset, then doing a
formal documentation is a fine thing to do. But if we think we can
actually come up with a new format which everyone is happy with, then
perhaps that's a more productive use of the package experts' energies.
(Of course, this is all a volunteer effort, so if someone wants to
step up to the task of spending time documenting all of the RPM header
tags and coming up with a formal specification, instead of some other
task, that's great! The Red Hat RPM maintainer has stated flately
that he's not interested in doing any such thing, so there's a
potential volunteer opportunity awaiting here.)
- Ted
Reply to: