Re: [Rpm-maint] RFC: experiments with rich dependencies

2015-01-14 Thread Michael Schroeder
On Wed, Jan 14, 2015 at 04:42:42AM -0500, Lubos Kardos wrote: > And this is problem I shouldn't be able to unistall package testB because it > is > required by testA. This problem was created in commit 8674de47 on line 2108 > in lib/rpmdb.c. The last char of string name is cut off no matter if tha

Re: [Rpm-maint] RFC: experiments with rich dependencies

2015-01-14 Thread Lubos Kardos
atrequries test # Now without the last char testA-1-1.x86_64 testA-1-1.x86_64 Lubos - Original Message - > From: "Michael Schroeder" > To: "Panu Matilainen" > Cc: rpm-maint@lists.rpm.org > Sent: Friday, September 12, 2014 6:06:15 PM > Subjec

Re: [Rpm-maint] RFC: experiments with rich dependencies

2014-09-12 Thread Michael Schroeder
On Thu, Sep 11, 2014 at 03:18:19PM +0300, Panu Matilainen wrote: > With rpm 4.12 branched out and new development cycle just starting, this > would be the prime time to land in such big new features and AFAICS this > would make for a fine starting point for further refining. I'd say go ahead > a

Re: [Rpm-maint] RFC: experiments with rich dependencies

2014-09-11 Thread Michael Schroeder
On Thu, Sep 11, 2014 at 03:02:15PM +0200, Florian Festi wrote: > On 09/11/2014 02:51 PM, Michael Schroeder wrote: > > Ah, but I was hoping for a discussion of the syntax. Are you ok with > > the enclosing the rich deps with ()? What about the op names, I'd > > love to use & as 'and' and | as 'or' (

Re: [Rpm-maint] RFC: experiments with rich dependencies

2014-09-11 Thread Panu Matilainen
On 09/11/2014 03:51 PM, Michael Schroeder wrote: On Thu, Sep 11, 2014 at 03:18:19PM +0300, Panu Matilainen wrote: I did find one "unexpected complication" [*] in the concept in my brief testing, and in all likelihood there are more cases nobody thought of etc... Just like we're still finding unc

Re: [Rpm-maint] RFC: experiments with rich dependencies

2014-09-11 Thread Florian Festi
On 09/11/2014 02:51 PM, Michael Schroeder wrote: > Ah, but I was hoping for a discussion of the syntax. Are you ok with > the enclosing the rich deps with ()? What about the op names, I'd > love to use & as 'and' and | as 'or' (which also makes it more like > Debian), but I can't think of any good

Re: [Rpm-maint] RFC: experiments with rich dependencies

2014-09-11 Thread Michael Schroeder
On Thu, Sep 11, 2014 at 03:18:19PM +0300, Panu Matilainen wrote: > I did find one "unexpected complication" [*] in the concept in my brief > testing, and in all likelihood there are more cases nobody thought of > etc... Just like we're still finding uncovered cases with the plain old > provide/r

Re: [Rpm-maint] RFC: experiments with rich dependencies

2014-09-11 Thread Florian Festi
On 09/11/2014 02:18 PM, Panu Matilainen wrote: > [*] IF-dependencies have similar issues as reverse dependencies: one can > break somebody elses dependencies by installing some seemingly unrelated > package. Perhaps they should be limited to weak dependencies. That's not exactly the same situation

Re: [Rpm-maint] RFC: experiments with rich dependencies

2014-09-11 Thread Panu Matilainen
On 09/09/2014 06:33 PM, Michael Schroeder wrote: On Mon, Sep 08, 2014 at 04:51:12PM +0200, Michael Schroeder wrote: Hi Panu et al, Hi, attached is an updated version of my rich dependencies patch. I cleanup up the code a bit, now we have only one generic parser instead of three specialized

Re: [Rpm-maint] RFC: experiments with rich dependencies

2014-09-09 Thread Michael Schroeder
On Mon, Sep 08, 2014 at 04:51:12PM +0200, Michael Schroeder wrote: > Hi Panu et al, > > attached is an updated version of my rich dependencies patch. > I cleanup up the code a bit, now we have only one generic parser > instead of three specialized ones, and we use a callback function > to do the n

[Rpm-maint] RFC: experiments with rich dependencies

2014-09-08 Thread Michael Schroeder
Hi Panu et al, attached is an updated version of my rich dependencies patch. I cleanup up the code a bit, now we have only one generic parser instead of three specialized ones, and we use a callback function to do the needed work. Supported are AND, OR, and IF, but IF is not allowd in Conflicts,