[Rpm-metadata] Debian metadata (was Re: format misc)

Jeff Johnson jbj at redhat.com
Thu Oct 9 00:10:44 UTC 2003


On Wed, Oct 08, 2003 at 05:22:29PM -0500, Jeff Licquia wrote:
> On Wed, 2003-10-08 at 16:39, Jeff Johnson wrote:
> > Jeff Licquia wrote:
> > >Oops.  Sorry for bringing up an old boat-anchor.
> > 
> > NP, we all have our crosses to bear. I hear Suggests: has hysterical 
> > legacy too ;-)
> 
> Recommends and Suggests have been interesting, both from technical and
> political points of view.  But they're still considered proper Debian
> practice, unlike (it seems) PreReq.
> 

PreReq: is synonym for Requires:, legacy usage permitted in spec files.
Exposing in new development is what makes me squawk.

Perhaps Suggests: and Recommends: might become synonyms too?

> > >Debian needs Pre-Depends because dpkg batches unpack and configure
> > >stages of package installs; Pre-Depends forces dpkg to batch a package
> > >and its dependency in separate batches, so the dependency is fully
> > >installed before the other package install starts.
> > 
> > I might be able suggest alternative means in dpkg to handle this 
> > situation if you wish.
> 
> You've pricked my professional curiosity; how?
> 
> Although it is off-topic; maybe personal mail?  Unless everyone else is
> really hankering for a technical discussion of dpkg. :-)
> 

Catch me on rpm-devel at colug.net (not yet public, announce in a week or two),
where you will find me attempting a unified package manager project
for linux. Wish me luck!

> > If I'm vendor neutral, I note that SuSE still uses rpm-3.0.6, and there 
> > might (I can't
> > figger any need and  I don't know of any current depsolvers based on 
> > rpm-3.0.6. Well there's
> > apt-rpm, but I believe the rpm-3.0.x support is almost, but not quite, 
> > history) be
> > reasons to expose PreReq:. If you absolutely must, then other tokens 
> > could be added to
> > the Flags element to expose the PreReq: bit. If you go this pathway, 
> > there are other
> > context bits that probably need expose too. Please coordinate the 
> > changes with me,
> > as I have to figger what I can commit rpm to support, and what is gonna 
> > need rework
> > before being generally useful and maintainable.
> 
> My attitude here is to be as little of a pain as possible, since we
> Debian folk are kind of horning in.  This is the *rpm* metadata list,
> after all.  But I think it's obvious that there are benefits if the
> rpm-metadata format is flexible enough to handle deb as well.
> 
> So I'm not opposed to whatever proposal seems the best from the RPM
> side, as long as we Debian folk have some way of divining the things we
> need.  I was just wondering if RPM had something like Pre-Depends so we
> could avoid Balkanizing the namespace.
> 

Consensus is the key issue, there's little need to politicize through
advocacy of depsolvers as in the past.

All depsolvers are showing their age, even yum ;-)

So, I'm very happy to see Debian involvement.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC



More information about the Rpm-metadata mailing list