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

[Jeff Johnson]

Jeff Licquia wrote:

>On Wed, 2003-10-08 at 15:45, Jeff Johnson wrote:
>  
>
>>Jeff Licquia wrote:
>>    
>>
>>>FWIW, RPM does have Pre-Depends.  It's called "PreReq".
>>>      
>>>
>>Please, please, please let PreReq: die, there is absolutely no reason to 
>>distinguish
>>this marker (for rpm purposes) any more.
>>    
>>
>
>Oops.  Sorry for bringing up an old boat-anchor.
>  
>

NP, we all have our crosses to bear. I hear Suggests: has hysterical 
legacy too ;-)

>  
>
>>>So, the mapping should be:
>>>
>>>Depends: -> <requires>
>>>Pre-Depends: -> <prereq>
>>>      
>>>
>>OTOH, if apt needs syntax to express Pre-Depends, then I'm all in favor of
>>permitting the XML syntax. Just please, please, please do not use for 
>>rpm purposes,
>>Requires: is more than sufficient, and you cannot possibly need to 
>>expose this legacy
>>artifact to any kinown rpm depsolver.
>>    
>>
>
>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.

>I'm not aware of apt-rpm needing PreReq-style functionality; its
>dependency tree should be correct as you describe.
>
>If RPM PreReq needs to die, then I'm not opposed to some other syntax,
>so as not to confuse the RPM side.
>  
>

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.

Still I'd suggest not exposing information needlessly. And it might be 
time to get
SuSE and/or MDK representatives on this list too to ensure consensus.

73 de Jeff