[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