Re: [gentoo-portage-dev] Conflicting RDEPENDS

2009-05-29 Thread Patrick Börjesson
On Fri, May 29, 2009 at 01:36:20AM +0200, René 'Necoro' Neumann wrote:
> Package "spam" rdepends on "=eggs-2".
> Package "bacon" rdepends on "=eggs-1".
> 
> So in theory there should be no way of installing them together (given
> that eggs is not slotted). This works if I try to install them in one go.
> 
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
> 
> app-test/eggs:0
> 
>   ('ebuild', '/', 'app-test/eggs-2', 'merge') pulled in by
> =app-test/eggs-2 required by ('ebuild', '/', 'app-test/spam-1', 'merge')
> 
>   ('ebuild', '/', 'app-test/eggs-1', 'merge') pulled in by
> =app-test/eggs-1 required by ('ebuild', '/', 'app-test/bacon-1',
> 'merge')
> 
> 
> It looks different, if spam is installed and I try to install bacon
> additionally:
> 
> # emerge -1av bacon
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild UD] app-test/eggs-1 [2] 0 kB [1]
> [ebuild  N] app-test/bacon-1  0 kB [1]
> 
> 
> This second behavior looks wrong to me, as it downgrades the RDEPEND of
> spam and thus spam becomes unusable.

Try: emerge -1av --complete-graph bacon

Unless --complete-graph is specified emerge won't pull in the entire
dependency graph, thus won't notice the dependency-spec of
app-test/spam. 
Using -D combined with the world set when updating your system yields
the same result as that also pulls in the entire dependency graph. 

Unless the entire dependency graph is pulled in emerge only tries to
satisfy the dependencies of the packages given on the commandline, and
since there's no "connection" between app-test/spam and app-test/bacon,
and emerge doesn't do reverse deps when adding something to the
dep-graph, it doesn't notice that app-test/bacon and app-test/spam has
conflicting dependencies

Using --complete-graph is noticably slower since it slows down
dependency calculations, but it should (IMHO) really be the default
since these conflicts shows _before_ anything breaks. 



Re: [gentoo-portage-dev] Conflicting RDEPENDS

2009-05-29 Thread René 'Necoro' Neumann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ferris McCormick schrieb:
>> It looks different, if spam is installed and I try to install bacon
>> additionally:
> 
>> # emerge -1av bacon
> 
>> These are the packages that would be merged, in order:
> 
>> Calculating dependencies... done!
>> [ebuild UD] app-test/eggs-1 [2] 0 kB [1]
>> [ebuild  N] app-test/bacon-1  0 kB [1]
> 
> 
> What happens if you use
> emerge -1avD bacon
> 

Does not work either.

>> This second behavior looks wrong to me, as it downgrades the RDEPEND of
>> spam and thus spam becomes unusable.
> 
> 
> Yeah, it does look wrong, but I don't think it is.  Ideally, I suppose
> eggs-1 could depend on !=app-test/spam-1 and so on, but that requires
> coordination among developers.  I suppose there is a bug in the ebuilds
> because they should be set up so that if you have spam installed, you
> can't install bacon and so on.

I think, this would be the wrong way., as they block each other already
because of the RDEPEND. Else one would have to check the whole tree for
a conflicting RDEPEND and then adding a whole bunch of blocks.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkofqzsACgkQ4UOg/zhYFuD4XQCeKUuemmNjWr7shtgsttc93sro
1U0An0SrsWexvLUmYtvzyjokpZiQyqSm
=vvTO
-END PGP SIGNATURE-



Re: [gentoo-portage-dev] Conflicting RDEPENDS

2009-05-29 Thread René 'Necoro' Neumann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Patrick Börjesson schrieb:
>>
>> # emerge -1av bacon
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild UD] app-test/eggs-1 [2] 0 kB [1]
>> [ebuild  N] app-test/bacon-1  0 kB [1]
>>
>>
>> This second behavior looks wrong to me, as it downgrades the RDEPEND of
>> spam and thus spam becomes unusable.
> 
> Try: emerge -1av --complete-graph bacon

Ok - this works ... IF spam is in world. If I installed spam with
- --oneshot, it won't work either.

> Unless --complete-graph is specified emerge won't pull in the entire
> dependency graph, thus won't notice the dependency-spec of
> app-test/spam. 
> Using -D combined with the world set when updating your system yields
> the same result as that also pulls in the entire dependency graph. 
> 
> Unless the entire dependency graph is pulled in emerge only tries to
> satisfy the dependencies of the packages given on the commandline, and
> since there's no "connection" between app-test/spam and app-test/bacon,
> and emerge doesn't do reverse deps when adding something to the
> dep-graph, it doesn't notice that app-test/bacon and app-test/spam has
> conflicting dependencies
> 
> Using --complete-graph is noticably slower since it slows down
> dependency calculations, but it should (IMHO) really be the default
> since these conflicts shows _before_ anything breaks. 

I agree.

Regards,
René
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkofq+sACgkQ4UOg/zhYFuBhsACdEUiXen0NriASzULe0Ak9Waiv
6v8An1OxTqmbnhlCk7sRG0pYxfHJad8Y
=Haya
-END PGP SIGNATURE-



Re: [gentoo-portage-dev] Conflicting RDEPENDS

2009-05-29 Thread Alec Warner
On Fri, May 29, 2009 at 2:33 AM, René 'Necoro' Neumann  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Patrick Börjesson schrieb:
>>>
>>> # emerge -1av bacon
>>>
>>> These are the packages that would be merged, in order:
>>>
>>> Calculating dependencies... done!
>>> [ebuild UD] app-test/eggs-1 [2] 0 kB [1]
>>> [ebuild  N] app-test/bacon-1  0 kB [1]
>>>
>>>
>>> This second behavior looks wrong to me, as it downgrades the RDEPEND of
>>> spam and thus spam becomes unusable.
>>
>> Try: emerge -1av --complete-graph bacon
>
> Ok - this works ... IF spam is in world. If I installed spam with
> - --oneshot, it won't work either.

So don't use --oneshot :)

>
>> Unless --complete-graph is specified emerge won't pull in the entire
>> dependency graph, thus won't notice the dependency-spec of
>> app-test/spam.
>> Using -D combined with the world set when updating your system yields
>> the same result as that also pulls in the entire dependency graph.
>>
>> Unless the entire dependency graph is pulled in emerge only tries to
>> satisfy the dependencies of the packages given on the commandline, and
>> since there's no "connection" between app-test/spam and app-test/bacon,
>> and emerge doesn't do reverse deps when adding something to the
>> dep-graph, it doesn't notice that app-test/bacon and app-test/spam has
>> conflicting dependencies
>>
>> Using --complete-graph is noticably slower since it slows down
>> dependency calculations, but it should (IMHO) really be the default
>> since these conflicts shows _before_ anything breaks.
>
> I agree.
>
> Regards,
> René
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkofq+sACgkQ4UOg/zhYFuBhsACdEUiXen0NriASzULe0Ak9Waiv
> 6v8An1OxTqmbnhlCk7sRG0pYxfHJad8Y
> =Haya
> -END PGP SIGNATURE-
>
>



Re: [gentoo-portage-dev] Conflicting RDEPENDS

2009-05-29 Thread Patrick Börjesson
On Fri, May 29, 2009 at 11:33:31AM +0200, René 'Necoro' Neumann wrote:
> Patrick Börjesson schrieb:
> >>
> >> # emerge -1av bacon
> >>
> >> These are the packages that would be merged, in order:
> >>
> >> Calculating dependencies... done!
> >> [ebuild UD] app-test/eggs-1 [2] 0 kB [1]
> >> [ebuild  N] app-test/bacon-1  0 kB [1]
> >>
> >>
> >> This second behavior looks wrong to me, as it downgrades the RDEPEND of
> >> spam and thus spam becomes unusable.
> > 
> > Try: emerge -1av --complete-graph bacon
> 
> Ok - this works ... IF spam is in world. If I installed spam with
> --oneshot, it won't work either.

Why exactly would you want to use --oneshot for a "leaf package" that is
not depended on by any other package in the world set? If spam IS
depended on by any other package (recursively) in the world set, it will
be pulled in by --complete-graph, but that's not the case here if i
understand it correctly, thus it's a package that you explicitly wanted
installed, thus it belongs in the world set, and you should thus not use
--oneshot for it.




[gentoo-portage-dev] Re: Conflicting RDEPENDS

2009-05-29 Thread Duncan
Patrick Börjesson  posted
20090529201741.gb11...@nexon.nexus, excerpted below, on  Fri, 29 May 2009
22:17:41 +0200:

> Why exactly would you want to use --oneshot for a "leaf package" that is
> not depended on by any other package in the world set? If spam IS
> depended on by any other package (recursively) in the world set, it will
> be pulled in by --complete-graph, but that's not the case here if i
> understand it correctly, thus it's a package that you explicitly wanted
> installed, thus it belongs in the world set, and you should thus not use
> --oneshot for it.

I use -1 by default, here (via scriptlet), mainly so I don't have to 
worry about cluttering up my world file while emerging individual 
packages, just as I always use -NuD with my @system and @world runs.

But for leaf packages, it serves as a sort of test install as well.  
Since I always do revdep-rebuild -p and emerge --depclean -p after every 
update (typically 2-3 times a week), then rebuild and clean as I need to, 
keeping the "trial merges" on the depclean list for a few days keeps me 
aware of them.  If I know it's something I want to keep, I run a 
different scriptlet without the -1, but that's not often once a system is 
up and running with the normal working set merged.  Meanwhile, I 
ultimately either emerge -C (or let depclean handle it) the "trialware", 
or emerge --noreplace, thus adding it to world.

But experimental installs and their deps typically sit in the --depclean 
list for anything from a few minutes to a few days, until I decide 
whether I want to keep or remove them.

If he was testing how the switches under discussion here worked and has a 
similar policy, I could easily see him using -1 by habit, even if he 
didn't explicitly reason that it was a test and therefore something he 
didn't want in @world.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman