On Mar 14, 2008, at 10:02 PM, Olivier Thauvin wrote:

> Le samedi 15 mars 2008, Jeff Johnson a écrit :
>> Um, please start some discussion before just adding
>> two new dependency types to rpmds.
>>
>> I'm strongly opposed to adding 2 new dependency types
>> within package content.
>>
>> RPMSENSE_MISSINGOK to modify the meaning of existing
>> Requires: and Provides: is more than sufficient.
>
> I did it (and btw send the same patch to rpm.org) to being able to  
> query
> headers for thoses dependencies, which are already use in mandriva  
> (rpm.org).
>

But Suggests: and Enhances: are not in use in either rpm.org or  
rpm5.org code bases
(or you would not have sent the patch).

Mandriva can do what it wishes, just like SuSE has.

The end result _ALREADY_ has several different representations in  
*.rpm packages
for Suggests: and Enhances:.

I personally am strongly opposed to having multiple means to
represent information that is not yet deployed (3+ years after
I added a single bit to an existing tag), and that has no clearly
implemented semantic in any known installer (other than SuSE's
SAT solver). Perhaps PLD has done something sensible (as usual).

I point out that rpm5 _ALREADY_ also has arbitrary tags. There
is nothing at all stopping you from configuring

     #
     # Colon separated list of permitted arbitrary tag names
    %_arbitrary_tags         
Class:Track:Trackprog:Foo:Bar:Baz:Suggests:Enhances

and populating packages with strings that can be used for whatever  
purpose
you choose, including Suggests: and Enhances: and Categories: and ...

The is also no reason -- if you wish to use a rpmds container -- in  
coding

     #define _RPMDS_INTERNAL
     #include <rpmds.h>

and populating a rpmds structure however you choose using headerGet().

And finally, if Mandriva (or you) is clearly focussed on this patch  
in code that they
choose not to use, well, there's a whole mechanism for vendor- 
specific patches
under

#if defined(RPM_VENDOR_MANDRIVA)
...
#endif

Adding the code directly to HEAD implies a direction and an intention  
to support Suggests: and Enhances:
represented within package headers that is perhaps not true.

The fundamental design problem I see is that if you add, say,  
Suggests: to a package and burn it
into an ISO, you are stuck with that data (often) for years. No one  
can guess how
    Suggests: kernel > 2.6.33
or
    Enhances kernel < 2.6.33
should be interpreted in the year 2010.

> It seems to me logical to being able to rpmdsNew for all  
> dependencies types
> exinsting in our tags list.
>
> But I never planned to have any usage of it in rpm5.org (except  
> listing them).
>
> For the notice, it is for sophie (sophie.zarb.org), and I also  
> d'like to
> implement query on dirname/linkto dependencies. But... since sophie  
> is hosted
> on a mandriva, since mandriva use rpm.org, and since rpm.org don't  
> handle
> theses last specific dependencies, I don't know how I will do...  
> (linking
> pgrpm module over rpm5 instead system rpm ??)...

Try adding a

    #if defined(RPM_VENDOR_ZARB)
    ...
    #endif

I have much less of a problem with the patch per se than with the  
implications and
rumor mongering associated with adding Suggests: and Enhances:.

For dirname/linkto dependencies, RPMTAG_DIRNAMES and RPMTAG_FILELINKTOS
already exist. The difference with Suggests:/Enhances: is that a  
{N,EVR,F} triple
is used, which leads to a fair amount of complexity.

Adding Michael Schroeder's libsatsolver (or more likely equivalent  
implementation)
as an alternative dependency engine is looming on my todo list rapidly.

WIth a clearer idea of what a desirable semantic for Suggests: and  
Enhances: should be, then
perhaps a rpmds container will be the correct implementation, and  
there will be some
idea of how the information should be represented.

I can't answer any of those questions yet. It's way too early ...

73 de Jeff