[gentoo-user] do subslots improve user-experience?

[gentoo-user] do subslots improve user-experience?

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Another round of questioning the users here.

more specifically:
* how often do you experience useless rebuilds?
* do you really have a problem with running
revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?
* do you think it's worth the effort to add more stuff to the PM, so
that you don't have to run revdep-rebuild that often?
* do you trust the other methods like subslots or preserved-rebuild to
work reliably? (as in: do you still use revdep-rebuild?)

If you want my opinion on subslots:
# grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSdOpkAAoJEFpvPKfnPDWzJv4IAJXrLhHVJwsc4e1rqsKeA8MP
4NWYVPLlWpcCBibd4bH6T+nIc3u0Nw7sDVprVn2clZeN7jXNftUfnGVWi2gKFg5c
TserKHr9/rVAwgOEl6O8x8aR9JbvBpAevWHwxOJ066JeLgY3ziNOlU+Y0Yo4c7CN
TcmxjOyPTdhaYpcfR2KLfyNkbXHSMwImHCQcjNt7zbYXaKP6UOxCPR4ihOZUjrp5
c8eWQyrfh8Ubgk0RlpbqGN7SAkIv2ERWlQgyXY+PI4SbQNM/Jou3tbyt+De5b815
8gwrXOYEp+t/HfmDEtAGuGHQzdfu5sUev6/IVnpnnXFSLwrvR3wjuSSeCaIlrx4=
=eAyd
-----END PGP SIGNATURE-----

Re: [gentoo-user] do subslots improve user-experience?

[Philip Webb]

131102 hasufell had some more questions for users :
> * how often do you experience useless rebuilds?

Not recently : it used to happen more often.

> * do you really have a problem with running
> revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?

No.

> * do you think it's worth the effort to add more stuff to the PM,
> so that you don't have to run revdep-rebuild that often?

No, as I don't need R-R anymore.

> * do you trust the other methods like subslots or preserved-rebuild
> to work reliably? -- do you still use revdep-rebuild?

P-R seems to work adequately.

My big gripe is unnecessary dependencies, eg sound for KDE & FF.
It's part of the lowest-common-denominator approach
which seems to characterise Gnome, Ubuntu & M$ , but Gentoo should avoid.
That said, I'm generally very satisfied with Gentoo :
it's just over  10 years  since I first started using it.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] do subslots improve user-experience?

[Alan McKinnon]

On 02/11/2013 14:04, hasufell wrote:
> Another round of questioning the users here.
> 
> more specifically:
> * how often do you experience useless rebuilds?

Let's see, that depends.

It mostly mostly on what is happening with poppler and icu today.

Other than those, I don't recall any long-term problems relating to
useless rebuilds; by and large they seem to be valid

> * do you really have a problem with running
> revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?

No, no problem whatsoever. emerge @preserved -rebuild is my preferred
method, I find it vastly superior to sub-slot operators which

a) involve weird magic in the ebuild and
b) I still don't understand despite reading all the docs I can find on
the matter.

The problem seems to be that preserved-rebuild and revdep-rebuild detect
actual breakage and fix what is really wrong right now.

Subslots seem to try and avoid breakage and depend heavily on amount of
clue from the dev (a highly variable quantity)

> * do you think it's worth the effort to add more stuff to the PM, so
> that you don't have to run revdep-rebuild that often?

No, subslots should be obsoleted, I consider them a failed experiment in
unnecessary complexity. emerge world is already long-running, if I had a
problem with a few more steps after it completes I would write a wrapper
script

> * do you trust the other methods like subslots or preserved-rebuild to
> work reliably? (as in: do you still use revdep-rebuild?)

yes, revdep-rebuild is my plan C. Occasionally it finds something,
usually itcompletes in about 40 secodns and is clean. I consider those
40 seconds well spent, a final confirmation step

> 
> If you want my opinion on subslots:
> # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
> 

-- 
Alan McKinnon
Systems Engineer^W Technician
Infrastructure Services
Internet Solutions

+27 11 575 7585


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: do subslots improve user-experience?

[Martin Vaeth]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> No, no problem whatsoever. emerge @preserved -rebuild is my preferred
> method, I find it vastly superior to sub-slot operators which

It is neither superior nor inferior.

It is an unrelated mechanism which will have less to do
once subslot dependencies are more widespread.

However, some dependencies in the tree are not yet EAPI5,
and moreover, some dependencies in some overlays can never
make use of subslots if these subslots are not in the
corresponding dependencies of the gentoo tree (e.g. because
these subslots are not needed for the packages *in* the tree).

So revdep-rebuild will never become obsolete.

> The problem seems to be that preserved-rebuild and revdep-rebuild detect
> actual breakage and fix what is really wrong right now.

The problem is that preserved-rebuild and revdep-rebuild only
detect one particular type of breakage.

Here is a real-world example: One day I realized that pdflatex
crashed for me, and neither revdep-rebuild found something
nor reemerge of texlive-core helped.

I spent several hours of debugging and finally found that the
cause was a poppler -r1 fix which tacitly changed some ABI which
caused luatex to crash.  So actually, it was luatex which needed
to be reemerged.

The bug was closed as INVALID because the developer had the
opinion that everybody knows that if poppler has any minor bump,
all packages depending on poppler have to be reemerged.
In fact, these days there were no mechanisms (except for
perhaps a pkg_postinst message of the form "reemerge everything
depending on poppler") which could inform the user what should
be done so closing this bug was the only thing which could be done.

Similar issues occured regularly with webdav-neon: Although
the ABI was changed, the libraries version number was not,
and so e.g. subversion tacitly crashed or malfunctioned.
Revdep-rebuild could never find anything in such a situtation.

As another, well-known, example, probably most of us ran
into the issue of having to reemerge X drivers after an xorg bump
or otherwise keyboard and mouse just will not work.

I am very glad that now such issues do not occur anymore:
After a while, one knows the problematic packages, but from
time to time new unexpected issues like the above examples
arise.

> Subslots seem to try and avoid breakage and depend heavily on amount of
> clue from the dev (a highly variable quantity)

Not much clue: If the dev is in doubt, he just bumps the subslot.
This way things are guaranteed to work, although some rebuilds
caused by the bump might be unnecessary.
But *not* bumping should really be done only if the developer is
sure that there is no ABI change.

In case of poppler, things are even more complicated, because
there is one library which regularly changes ABI, although that
particular library is not consumed by most packages.  So actually
subslots are not fine enough to avoid unnecessary rebuilds, or
the poppler package should be split into two to avoid
unnecessary rebuilds.

>> * do you trust the other methods like subslots or preserved-rebuild to
>> work reliably? (as in: do you still use revdep-rebuild?)
>
> yes, revdep-rebuild is my plan C.

Indeed, as mentioned above, subslots will never replace
revdep-rebuild.
preserved-rebuild is meant to replace it, but there might
be some corner cases where it does not detect a change (e.g.
if some important things are done only in the live system).

> usually itcompletes in about 40 secodns and is clean.

For me, it needs about 10-20 minutes if everything is clean.

But then again, also reemerging libreoffice needs 2-3 days,
and it would be a week or even infinite without ccache
(because for unknown reasons, the first emerge attempts
usually fail non-reproducible).

>> If you want my opinion on subslots:
>> # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
>> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"

A different user interface would be preferrable:
Something like FEATURES=show-built-slot-operator-deps
which would *show* what would need to be rebuilt even
if the above EMERGE_DEFAULT_OPTS is used.
This is then something which users with less powerful
machines like me can put into their make.conf and then
decide from case to case whether/when to rebuild.

Or even better: In --ask mode, one could ask the user
in addition for those packages only pulled in by
subslot deps.

This way users with not so powerful machines would be
informed regularly but would not be forced to call
emerge twice or more times just to get the information
(which meanwhile is really a time issue).

The current way of reemerging subslots by default
might (and IMHO should) be kept, anyway.

Re: [gentoo-user] Re: do subslots improve user-experience?

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/03/2013 08:07 PM, Martin Vaeth wrote:
>>> If you want my opinion on subslots: # grep EMERGE_DEFAULT_OPTS
>>> /etc/portage/make.conf 
>>> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
> 
> A different user interface would be preferrable: Something like
> FEATURES=show-built-slot-operator-deps which would *show* what
> would need to be rebuilt even if the above EMERGE_DEFAULT_OPTS is
> used. This is then something which users with less powerful 
> machines like me can put into their make.conf and then decide from
> case to case whether/when to rebuild.
> 
> Or even better: In --ask mode, one could ask the user in addition
> for those packages only pulled in by subslot deps.
> 
> This way users with not so powerful machines would be informed
> regularly but would not be forced to call emerge twice or more
> times just to get the information (which meanwhile is really a time
> issue).
> 
> The current way of reemerging subslots by default might (and IMHO
> should) be kept, anyway.
> 
> 

Could you open a bug report for portage and make a properly formulated
proposal about this?

I think this idea has a realistic chance to get implemented, one way
or the other.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSdqKjAAoJEFpvPKfnPDWzQ/0IAJ+S1CyBxLfd6TxQeer1dP+K
JZYTG/6CDVEegpyLzypTB5TqlQeyk4p2BKIdE28Cgm48GIMiDGn3IsZIgELlc85b
iCztw1l6aCSLtAxA1ck4b2N9jHU6z91+QFXfs1XSJ8uGdb7jZJtR6THS9Clzl4NL
JvMRX1Cr0ZPsmzNLG7U/jcQ+FAhygeV6N4GFifcPRXOk9hqdpDahLsqlZ91OENn+
uC6taKJIgjElBHkc/sITEaFqkcAFt3kX//WsQwjIANeEYYniSXe9ucNUWPg6Gf76
BGd5gNap0SA1D2b8VPGgEU12pLzUOB6V6ITcJZyTTVyTgm5QVvKn2RrHpcNXwsU=
=2zBZ
-----END PGP SIGNATURE-----

[gentoo-user] Re: do subslots improve user-experience?

[Martin Vaeth]

hasufell <hasufell@gentoo.org> wrote:
>
>>>> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
>>
>> A different user interface would be preferrable [...]
>
> Could you open a bug report for portage and make a properly formulated
> proposal about this?

Done. http://bugs.gentoo.org/show_bug.cgi?id=490350

Re: [gentoo-user] Re: do subslots improve user-experience?

[Alan McKinnon]

You know what? I'm not convinced.

What I'm seeing is a rather large towering edifice of complexity to deal
with a problem that is not the general case. I'm seeing something that
has all the hallmarks of a solution that whilst likely to be
mathematically correct, is dreamed up by young inexperienced coders and
will effectively cause more human problems than it solves code problems.

I don't want to rain on anyone's parade with this so if anyone feels
offended, maybe just let it go especially considering I have zero
decision making ability in this.







On 03/11/2013 21:07, Martin Vaeth wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>
>> No, no problem whatsoever. emerge @preserved -rebuild is my preferred
>> method, I find it vastly superior to sub-slot operators which
> 
> It is neither superior nor inferior.
> 
> It is an unrelated mechanism which will have less to do
> once subslot dependencies are more widespread.
> 
> However, some dependencies in the tree are not yet EAPI5,
> and moreover, some dependencies in some overlays can never
> make use of subslots if these subslots are not in the
> corresponding dependencies of the gentoo tree (e.g. because
> these subslots are not needed for the packages *in* the tree).
> 
> So revdep-rebuild will never become obsolete.
> 
>> The problem seems to be that preserved-rebuild and revdep-rebuild detect
>> actual breakage and fix what is really wrong right now.
> 
> The problem is that preserved-rebuild and revdep-rebuild only
> detect one particular type of breakage.
> 
> Here is a real-world example: One day I realized that pdflatex
> crashed for me, and neither revdep-rebuild found something
> nor reemerge of texlive-core helped.
> 
> I spent several hours of debugging and finally found that the
> cause was a poppler -r1 fix which tacitly changed some ABI which
> caused luatex to crash.  So actually, it was luatex which needed
> to be reemerged.
> 
> The bug was closed as INVALID because the developer had the
> opinion that everybody knows that if poppler has any minor bump,
> all packages depending on poppler have to be reemerged.
> In fact, these days there were no mechanisms (except for
> perhaps a pkg_postinst message of the form "reemerge everything
> depending on poppler") which could inform the user what should
> be done so closing this bug was the only thing which could be done.
> 
> Similar issues occured regularly with webdav-neon: Although
> the ABI was changed, the libraries version number was not,
> and so e.g. subversion tacitly crashed or malfunctioned.
> Revdep-rebuild could never find anything in such a situtation.
> 
> As another, well-known, example, probably most of us ran
> into the issue of having to reemerge X drivers after an xorg bump
> or otherwise keyboard and mouse just will not work.
> 
> I am very glad that now such issues do not occur anymore:
> After a while, one knows the problematic packages, but from
> time to time new unexpected issues like the above examples
> arise.
> 
>> Subslots seem to try and avoid breakage and depend heavily on amount of
>> clue from the dev (a highly variable quantity)
> 
> Not much clue: If the dev is in doubt, he just bumps the subslot.
> This way things are guaranteed to work, although some rebuilds
> caused by the bump might be unnecessary.
> But *not* bumping should really be done only if the developer is
> sure that there is no ABI change.
> 
> In case of poppler, things are even more complicated, because
> there is one library which regularly changes ABI, although that
> particular library is not consumed by most packages.  So actually
> subslots are not fine enough to avoid unnecessary rebuilds, or
> the poppler package should be split into two to avoid
> unnecessary rebuilds.
> 
>>> * do you trust the other methods like subslots or preserved-rebuild to
>>> work reliably? (as in: do you still use revdep-rebuild?)
>>
>> yes, revdep-rebuild is my plan C.
> 
> Indeed, as mentioned above, subslots will never replace
> revdep-rebuild.
> preserved-rebuild is meant to replace it, but there might
> be some corner cases where it does not detect a change (e.g.
> if some important things are done only in the live system).
> 
>> usually itcompletes in about 40 secodns and is clean.
> 
> For me, it needs about 10-20 minutes if everything is clean.
> 
> But then again, also reemerging libreoffice needs 2-3 days,
> and it would be a week or even infinite without ccache
> (because for unknown reasons, the first emerge attempts
> usually fail non-reproducible).
> 
>>> If you want my opinion on subslots:
>>> # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
>>> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
> 
> A different user interface would be preferrable:
> Something like FEATURES=show-built-slot-operator-deps
> which would *show* what would need to be rebuilt even
> if the above EMERGE_DEFAULT_OPTS is used.
> This is then something which users with less powerful
> machines like me can put into their make.conf and then
> decide from case to case whether/when to rebuild.
> 
> Or even better: In --ask mode, one could ask the user
> in addition for those packages only pulled in by
> subslot deps.
> 
> This way users with not so powerful machines would be
> informed regularly but would not be forced to call
> emerge twice or more times just to get the information
> (which meanwhile is really a time issue).
> 
> The current way of reemerging subslots by default
> might (and IMHO should) be kept, anyway.
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: do subslots improve user-experience?

[Martin Vaeth]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> You know what? I'm not convinced.
>
> What I'm seeing is a rather large towering edifice of complexity to deal
> with a problem that is not the general case.

I find it funny that perhaps you did not realize that you repeated
the main argument *in favour of subslots* on the dev mailing list:

Alan McKinnon <alan.mckinnon@gmail.com> wrote:

[ about emerge -e @world ]

> I've used this once or twice over the years to take care of inexplicable
> instability [...]

In fact, I bet that many gentoo users had the experience several times
over the years that reemerging the same(!) version of some package
mysteriously solves some problem.

> I strongly suspect the actual cause was inconsistencies around plug-in
> modules - the only thing I know of that portage and tools like
> revdep-rebuild can't really detect.

As I have just tried to explain, the cause was more likely the change
of some ABI without a change of the library version: revdep-rebuild can
only detect version changes, and there are some libraries like poppler
or neon (but probably many more I do not know) where upstream regularly
does such "tacit" ABI changes as a policy.

This was the main reason for introducing subslots!

(That it avoids using revdep-rebuild in many cases or calling things
like @x11-module-rebuild, python-updater, perl-updater, ... is only
a convenient side effect.
Subslots solve the plug-in modules problem, too, of course.)

With subslots emerge -e @world will in the long run never be necessary
anymore to get stability (it might of course still be necessary due to
a major toolchain change; also it does not catch cases where a
"tacit" ABI change happened by mistake and the developers failed to
see it.)

Note, however, "in the long run": The process of transforming all
packages to subslot dependencies is not yet complete.
I guess it will take many years until it is: Up to some corner cases
you can check whether the process is complete for your system when
(
	cd -- "$(portageq portdir)/metadata/md5-cache"
	grep -L '^EAPI=\([5-9]\|[1-9][0-9]\)' $(qlist -ICv)
)
does not output anything.

Re: [gentoo-user] Re: do subslots improve user-experience?

[Peter Humphrey]

On Tuesday 05 Nov 2013 10:52:36 Martin Vaeth wrote:

> Note, however, "in the long run": The process of transforming all
> packages to subslot dependencies is not yet complete.
> I guess it will take many years until it is: Up to some corner cases
> you can check whether the process is complete for your system when
> (
> 	cd -- "$(portageq portdir)/metadata/md5-cache"
> 	grep -L '^EAPI=\([5-9]\|[1-9][0-9]\)' $(qlist -ICv)
> )
> does not output anything.

Instructive - here it lists 507 packages!

-- 
Regards,
Peter

Re: [gentoo-user] Re: do subslots improve user-experience?

[Alan McKinnon]

On 05/11/2013 11:52, Martin Vaeth wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> You know what? I'm not convinced.
>>
>> What I'm seeing is a rather large towering edifice of complexity to deal
>> with a problem that is not the general case.
> 
> I find it funny that perhaps you did not realize that you repeated
> the main argument *in favour of subslots* on the dev mailing list:


It seems to me that you didn't read the whole post fully, and have
cherry-picked a part that you think bolsters your position. It does not.
So I will repeat myself in a different way.

I've run emerge -e world with the result of correcting something perhaps
2 or 3 times in 8 years. Let's assume that in the absence of portage
being able to detect those nasty errors, that this is reasonably
representative of the actual incidence of actual errors I encountered.
Let's then be generous and triple it.

In effect subslots appear to fix something for me about once a year. Is
my logic^Wguess flawed in any way?

So now we have a rather large complex system that deals with what is
essentially a minor problem that occurs say once a year.

I completely understand the problem sub-slots is trying to solve. I'm
just wondering if the methodology you are using to do it is valid, and
if it does not become the cure that is worse than the disease.

Consider for a moment the maintenance burden imposed on ebuild
maintainers, and how sub-slot notation is essentially added by humans
deploying human brains. And remember that humans are notoriously bad at
using mathematically correct solutions (they ... err ... forget to do
stuff).

sub-slots, whilst quite likely mathematically correct, has all the
hallmarks to me of SOMETHING THAT IS GOING TO FAIL DUE TO HUMANS. And
humans seldom do those things that they should do . If this were not so,
php would never have been written (just an arb random example)

I predict once a week fallout from sub-slots induced bugs that was
intended to fix once a year problem.

Do you now see why I'm not convinced this is a real-world solution?




> 
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
> [ about emerge -e @world ]
> 
>> I've used this once or twice over the years to take care of inexplicable
>> instability [...]
> 
> In fact, I bet that many gentoo users had the experience several times
> over the years that reemerging the same(!) version of some package
> mysteriously solves some problem.
> 
>> I strongly suspect the actual cause was inconsistencies around plug-in
>> modules - the only thing I know of that portage and tools like
>> revdep-rebuild can't really detect.
> 
> As I have just tried to explain, the cause was more likely the change
> of some ABI without a change of the library version: revdep-rebuild can
> only detect version changes, and there are some libraries like poppler
> or neon (but probably many more I do not know) where upstream regularly
> does such "tacit" ABI changes as a policy.
> 
> This was the main reason for introducing subslots!
> 
> (That it avoids using revdep-rebuild in many cases or calling things
> like @x11-module-rebuild, python-updater, perl-updater, ... is only
> a convenient side effect.
> Subslots solve the plug-in modules problem, too, of course.)
> 
> With subslots emerge -e @world will in the long run never be necessary
> anymore to get stability (it might of course still be necessary due to
> a major toolchain change; also it does not catch cases where a
> "tacit" ABI change happened by mistake and the developers failed to
> see it.)
> 
> Note, however, "in the long run": The process of transforming all
> packages to subslot dependencies is not yet complete.
> I guess it will take many years until it is: Up to some corner cases
> you can check whether the process is complete for your system when
> (
> 	cd -- "$(portageq portdir)/metadata/md5-cache"
> 	grep -L '^EAPI=\([5-9]\|[1-9][0-9]\)' $(qlist -ICv)
> )
> does not output anything.
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: do subslots improve user-experience?

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 5526 bytes --]

Am Tue, 05 Nov 2013 12:14:59 +0200
schrieb Alan McKinnon <alan.mckinnon@gmail.com>:

> On 05/11/2013 11:52, Martin Vaeth wrote:
> > Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >> You know what? I'm not convinced.
> >>
> >> What I'm seeing is a rather large towering edifice of complexity to deal
> >> with a problem that is not the general case.
> > 
> > I find it funny that perhaps you did not realize that you repeated
> > the main argument *in favour of subslots* on the dev mailing list:
> 
> 
> It seems to me that you didn't read the whole post fully, and have
> cherry-picked a part that you think bolsters your position. It does not.
> So I will repeat myself in a different way.
> 
> I've run emerge -e world with the result of correcting something perhaps
> 2 or 3 times in 8 years. Let's assume that in the absence of portage
> being able to detect those nasty errors, that this is reasonably
> representative of the actual incidence of actual errors I encountered.
> Let's then be generous and triple it.
> 
> In effect subslots appear to fix something for me about once a year. Is
> my logic^Wguess flawed in any way?

For *you*! You are not everyone, although I'm sure you already know that ;) .
See my Haskell example below for when subslots fix something more often.

> So now we have a rather large complex system that deals with what is
> essentially a minor problem that occurs say once a year.
> 
> I completely understand the problem sub-slots is trying to solve. I'm
> just wondering if the methodology you are using to do it is valid, and
> if it does not become the cure that is worse than the disease.
> 
> Consider for a moment the maintenance burden imposed on ebuild
> maintainers, and how sub-slot notation is essentially added by humans
> deploying human brains. And remember that humans are notoriously bad at
> using mathematically correct solutions (they ... err ... forget to do
> stuff).
> 
> sub-slots, whilst quite likely mathematically correct, has all the
> hallmarks to me of SOMETHING THAT IS GOING TO FAIL DUE TO HUMANS. And
> humans seldom do those things that they should do . If this were not so,
> php would never have been written (just an arb random example)
> 
> I predict once a week fallout from sub-slots induced bugs that was
> intended to fix once a year problem.
> 
> Do you now see why I'm not convinced this is a real-world solution?

I think I see your point, but what is the worst that can happen if somebody
gets a subslot wrong? Since too *many* rebuilds aren't all too terrible (a
waste of time for sure, and potentially annoying, but it won't outright break
anything), I suppose the worst case is too *few* automatic rebuilds, right? So
to me it sounds like you want to throw out the feature altogether because it
won't *always* catch everything. Or what potential bugs are you thinking about
that aren't useless rebuilds? I don't remember any from this thread, but of
course I could have missed something.

But what's the alternative? Telling the user to do it instead? That requires
human input, too: *somebody* has to write the elog message, and such that
any Gentoo user can understand it. Or is your point that one can look for
*fully* automatic solutions, as opposed to solutions where humans have to
provide input? I would expect the portage developers to have thought about it
for a while before settling with the subslot idea.

Now an example of my experience with subslots:

I use pandoc (used by IPython Notebook to convert notebooks to html or
whatever), and it -- along with all it's Haskell dependencies -- uses subslots.
That means that, whenever one of the Haskell dependencies updates, it
automatically rebuilds its reverse dependencies. And most of the time, it works
just fine! That's when I like subslots. Especially since the Haskell packages
are moving targets that update fairly often.

When it doesn't work, I'm stuck looking for what I have to rebuild. As a
matter of fact, I ran into such an issue just now: dev-haskell/texmath is
missing a dependency somewhere, so that pandoc would not compile (or run)
anymore after an upgrade to dev-haskell/aeson. Solution: recompile texmath
manually (a bug report will follow). That was simple, however, since the error
message of the Haskell compiler tells you which libraries are the problem. I
don't think I dislike subslots because of this. It's certainly nothing
preserved-rebuild or revdep-rebuild would find.

So, unless there's an at least equally good alternative, *no* subslots would
mean I would have to re-merge *all* dev-haskell packages after every update,
just to be on the safe side (or iteratively recompile according to what the
error message tells me until I finally catch all packages). I think that would
be slightly more terrible than forgotten subslots ;) .

--------------------

That said, one can certainly improve the "user interface" to subslots, and I
like the ideas put forth by Martin Väth in
https://bugs.gentoo.org/show_bug.cgi?id=490350. I especially like the idea of
having a dynamic set analogous to @preserved-rebuild (under the condition that
it also includes the updates that cause the rebuilds and not just the rebuilds
themselves, in order to avoid breakage). You could call it @subslot-rebuild ;)
or @subslot-upgrade.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: do subslots improve user-experience?

[Alan McKinnon]

On 05/11/2013 14:11, Marc Joliet wrote:
> Am Tue, 05 Nov 2013 12:14:59 +0200
> schrieb Alan McKinnon <alan.mckinnon@gmail.com>:
> 
>> On 05/11/2013 11:52, Martin Vaeth wrote:
>>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>> You know what? I'm not convinced.
>>>>
>>>> What I'm seeing is a rather large towering edifice of complexity to deal
>>>> with a problem that is not the general case.
>>>
>>> I find it funny that perhaps you did not realize that you repeated
>>> the main argument *in favour of subslots* on the dev mailing list:
>>
>>
>> It seems to me that you didn't read the whole post fully, and have
>> cherry-picked a part that you think bolsters your position. It does not.
>> So I will repeat myself in a different way.
>>
>> I've run emerge -e world with the result of correcting something perhaps
>> 2 or 3 times in 8 years. Let's assume that in the absence of portage
>> being able to detect those nasty errors, that this is reasonably
>> representative of the actual incidence of actual errors I encountered.
>> Let's then be generous and triple it.
>>
>> In effect subslots appear to fix something for me about once a year. Is
>> my logic^Wguess flawed in any way?
> 
> For *you*! You are not everyone, although I'm sure you already know that ;) .
> See my Haskell example below for when subslots fix something more often.
> 
>> So now we have a rather large complex system that deals with what is
>> essentially a minor problem that occurs say once a year.
>>
>> I completely understand the problem sub-slots is trying to solve. I'm
>> just wondering if the methodology you are using to do it is valid, and
>> if it does not become the cure that is worse than the disease.
>>
>> Consider for a moment the maintenance burden imposed on ebuild
>> maintainers, and how sub-slot notation is essentially added by humans
>> deploying human brains. And remember that humans are notoriously bad at
>> using mathematically correct solutions (they ... err ... forget to do
>> stuff).
>>
>> sub-slots, whilst quite likely mathematically correct, has all the
>> hallmarks to me of SOMETHING THAT IS GOING TO FAIL DUE TO HUMANS. And
>> humans seldom do those things that they should do . If this were not so,
>> php would never have been written (just an arb random example)
>>
>> I predict once a week fallout from sub-slots induced bugs that was
>> intended to fix once a year problem.
>>
>> Do you now see why I'm not convinced this is a real-world solution?
> 
> I think I see your point, but what is the worst that can happen if somebody
> gets a subslot wrong? Since too *many* rebuilds aren't all too terrible (a
> waste of time for sure, and potentially annoying, but it won't outright break
> anything), I suppose the worst case is too *few* automatic rebuilds, right? So
> to me it sounds like you want to throw out the feature altogether because it
> won't *always* catch everything. Or what potential bugs are you thinking about
> that aren't useless rebuilds? I don't remember any from this thread, but of
> course I could have missed something.



I too see your viewpoint, as you see mine. There's nothing wrong with
your logic within the narrow domain of making the code that implements
this specific feature (subslots) work correctly per spec.

Background: I'm a Linux sysadmin by day at an ISP. I constantly have to
contend with Devs and Devops writing bespoke code to implement business
rules. Because I sit three feet back from the problem, I can almost
always see the flaws with the solution. I can't give much details
unfortunately, my employer owns the code. But I get to be very very good
at spotting code that runs per spec, but is very brittle in the real
world. I look for tells like this:

- is the dev trying to get code deployed that is not fully tested?
- is the dev trying to ignore or minimize the real world effect on other
systems?
- can the dev show that someone else (not him) can actually maintain it,
configure it and understand it?
- Can every single person in his team rattle off the primary salient
points of the code without thinking much?
- Did the team who write the code write a doc on how to configure it,
and how to deal with possible failures they anticipate?
- If someone else (like eg me) gets this wrong and I make mistakes while
deploying, how will I know I've made a mistake? Do I get a sane error
message that a) describes the error in simple language and b) does not
make the fatal mistake of exposing the underlying implementation in
error messages?
- Do I need to read the code itself to gain even a high level
understanding of what the code does?

By now you will have guessed that nearby Dev team hate my guts with a
passion. Unlucky for them, I'm root and they ain't. Lucky for them, I'm
quite reasonable and happy to work together to get the questions
answered. With an answer of some kind, we can assess risk and make a
rational choice. Oftentimes it comes down to we write one detailed
technical doc and allay all fears.

I don't see these questions being answered wrt subslots. Maybe they were
answered and I haven't seen the link yet, maybe not. Maybe senior devs
with clue have thus far successfully modified ebuilds, maybe not. Maybe
more junior devshave yet to take their first steps, and maybe they will
royally screw things up by not understanding the syntax, or maybe not.

These questions have not been answered and I certainly don't have
answers; I also think neither do you. I would like to see this feature
extensively tested in de and stage before it hits production. Only then
can I decide for myself if subslots are a good solution to the stated
problem.


> 
> But what's the alternative? Telling the user to do it instead? That requires
> human input, too: *somebody* has to write the elog message, and such that
> any Gentoo user can understand it. Or is your point that one can look for
> *fully* automatic solutions, as opposed to solutions where humans have to
> provide input? I would expect the portage developers to have thought about it
> for a while before settling with the subslot idea.
> 
> Now an example of my experience with subslots:
> 
> I use pandoc (used by IPython Notebook to convert notebooks to html or
> whatever), and it -- along with all it's Haskell dependencies -- uses subslots.
> That means that, whenever one of the Haskell dependencies updates, it
> automatically rebuilds its reverse dependencies. And most of the time, it works
> just fine! That's when I like subslots. Especially since the Haskell packages
> are moving targets that update fairly often.
> 
> When it doesn't work, I'm stuck looking for what I have to rebuild. As a
> matter of fact, I ran into such an issue just now: dev-haskell/texmath is
> missing a dependency somewhere, so that pandoc would not compile (or run)
> anymore after an upgrade to dev-haskell/aeson. Solution: recompile texmath
> manually (a bug report will follow). That was simple, however, since the error
> message of the Haskell compiler tells you which libraries are the problem. I
> don't think I dislike subslots because of this. It's certainly nothing
> preserved-rebuild or revdep-rebuild would find.
> 
> So, unless there's an at least equally good alternative, *no* subslots would
> mean I would have to re-merge *all* dev-haskell packages after every update,
> just to be on the safe side (or iteratively recompile according to what the
> error message tells me until I finally catch all packages). I think that would
> be slightly more terrible than forgotten subslots ;) .
> 
> --------------------
> 
> That said, one can certainly improve the "user interface" to subslots, and I
> like the ideas put forth by Martin Väth in
> https://bugs.gentoo.org/show_bug.cgi?id=490350. I especially like the idea of
> having a dynamic set analogous to @preserved-rebuild (under the condition that
> it also includes the updates that cause the rebuilds and not just the rebuilds
> themselves, in order to avoid breakage). You could call it @subslot-rebuild ;)
> or @subslot-upgrade.
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: do subslots improve user-experience?

[Bruce Hill]

On Tue, Nov 05, 2013 at 04:44:43PM +0200, Alan McKinnon wrote:
> 
> I too see your viewpoint, as you see mine. There's nothing wrong with
> your logic within the narrow domain of making the code that implements
> this specific feature (subslots) work correctly per spec.
> 
> Background: I'm a Linux sysadmin by day at an ISP. I constantly have to
> contend with Devs and Devops writing bespoke code to implement business
> rules. Because I sit three feet back from the problem, I can almost
> always see the flaws with the solution. I can't give much details
> unfortunately, my employer owns the code. But I get to be very very good
> at spotting code that runs per spec, but is very brittle in the real
> world. I look for tells like this:
> 
> - is the dev trying to get code deployed that is not fully tested?
> - is the dev trying to ignore or minimize the real world effect on other
> systems?
> - can the dev show that someone else (not him) can actually maintain it,
> configure it and understand it?
> - Can every single person in his team rattle off the primary salient
> points of the code without thinking much?
> - Did the team who write the code write a doc on how to configure it,
> and how to deal with possible failures they anticipate?
> - If someone else (like eg me) gets this wrong and I make mistakes while
> deploying, how will I know I've made a mistake? Do I get a sane error
> message that a) describes the error in simple language and b) does not
> make the fatal mistake of exposing the underlying implementation in
> error messages?
> - Do I need to read the code itself to gain even a high level
> understanding of what the code does?

That is good practice, to say the least. Wish it would happen in Gentoo. But
then again, may I ask, do you have as many devs and as many pkgs that must
co-exist on so many differently configured machines?

My take is something like that should be implemented in Gentoo. But then, I
came from to Gentoo after 7+ years in Slackware. It happened your way there,
also, because of a BDFL. We don't have such in Gentoo.

The fact that 16939 packages in Gentoo mostly always work is amazing! Which
requires a lot of hands on deck; and they don't all have the same skills.

> By now you will have guessed that nearby Dev team hate my guts with a
> passion. Unlucky for them, I'm root and they ain't. Lucky for them, I'm
> quite reasonable and happy to work together to get the questions
> answered. With an answer of some kind, we can assess risk and make a
> rational choice. Oftentimes it comes down to we write one detailed
> technical doc and allay all fears.
> 
> I don't see these questions being answered wrt subslots. Maybe they were
> answered and I haven't seen the link yet, maybe not. Maybe senior devs
> with clue have thus far successfully modified ebuilds, maybe not. Maybe
> more junior devshave yet to take their first steps, and maybe they will
> royally screw things up by not understanding the syntax, or maybe not.
> 
> These questions have not been answered and I certainly don't have
> answers; I also think neither do you. I would like to see this feature
> extensively tested in de and stage before it hits production. Only then
> can I decide for myself if subslots are a good solution to the stated
> problem.

I've asked a very specific question about subslot philosophy as it pertains to
a specific situation on gentoo-dev.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: do subslots improve user-experience?

[Alan McKinnon]

On 05/11/2013 17:21, Bruce Hill wrote:
> That is good practice, to say the least. Wish it would happen in Gentoo. But
> then again, may I ask, do you have as many devs and as many pkgs that must
> co-exist on so many differently configured machines?

Not even close :-)

What we lack in package diversity we more than make up for with
"business requirements"; where in this context "business requirements"
somehow gets redefined to "license to do whatever the blazes you feel
like doing sans oversight".

Gentoo has a strong undercore of people who have all the reasons in the
world to do it right, without bean-counter interference. That alone
probably accounts for the miracle that it all somehow still works.
> 
> My take is something like that should be implemented in Gentoo. But then, I
> came from to Gentoo after 7+ years in Slackware. It happened your way there,
> also, because of a BDFL. We don't have such in Gentoo.
> 
> The fact that 16939 packages in Gentoo mostly always work is amazing! Which
> requires a lot of hands on deck; and they don't all have the same skills.

Indeed. All the more reason for peer pressure to lean in the direction
of doing it right and closely looking at the full impact on the entire
big picture. I know I'm whinging a bit on this topic right now, but also
feel it's appropriate to metnion that Gentoo does have an admirable
success track record over the years.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: do subslots improve user-experience?

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 8388 bytes --]

Am Tue, 05 Nov 2013 16:44:43 +0200
schrieb Alan McKinnon <alan.mckinnon@gmail.com>:

> On 05/11/2013 14:11, Marc Joliet wrote:
> > Am Tue, 05 Nov 2013 12:14:59 +0200
> > schrieb Alan McKinnon <alan.mckinnon@gmail.com>:
> > 
> >> On 05/11/2013 11:52, Martin Vaeth wrote:
> >>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >>>> You know what? I'm not convinced.
> >>>>
> >>>> What I'm seeing is a rather large towering edifice of complexity to deal
> >>>> with a problem that is not the general case.
> >>>
> >>> I find it funny that perhaps you did not realize that you repeated
> >>> the main argument *in favour of subslots* on the dev mailing list:
> >>
> >>
> >> It seems to me that you didn't read the whole post fully, and have
> >> cherry-picked a part that you think bolsters your position. It does not.
> >> So I will repeat myself in a different way.
> >>
> >> I've run emerge -e world with the result of correcting something perhaps
> >> 2 or 3 times in 8 years. Let's assume that in the absence of portage
> >> being able to detect those nasty errors, that this is reasonably
> >> representative of the actual incidence of actual errors I encountered.
> >> Let's then be generous and triple it.
> >>
> >> In effect subslots appear to fix something for me about once a year. Is
> >> my logic^Wguess flawed in any way?
> > 
> > For *you*! You are not everyone, although I'm sure you already know that ;) .
> > See my Haskell example below for when subslots fix something more often.
> > 
> >> So now we have a rather large complex system that deals with what is
> >> essentially a minor problem that occurs say once a year.
> >>
> >> I completely understand the problem sub-slots is trying to solve. I'm
> >> just wondering if the methodology you are using to do it is valid, and
> >> if it does not become the cure that is worse than the disease.
> >>
> >> Consider for a moment the maintenance burden imposed on ebuild
> >> maintainers, and how sub-slot notation is essentially added by humans
> >> deploying human brains. And remember that humans are notoriously bad at
> >> using mathematically correct solutions (they ... err ... forget to do
> >> stuff).
> >>
> >> sub-slots, whilst quite likely mathematically correct, has all the
> >> hallmarks to me of SOMETHING THAT IS GOING TO FAIL DUE TO HUMANS. And
> >> humans seldom do those things that they should do . If this were not so,
> >> php would never have been written (just an arb random example)
> >>
> >> I predict once a week fallout from sub-slots induced bugs that was
> >> intended to fix once a year problem.
> >>
> >> Do you now see why I'm not convinced this is a real-world solution?
> > 
> > I think I see your point, but what is the worst that can happen if somebody
> > gets a subslot wrong? Since too *many* rebuilds aren't all too terrible (a
> > waste of time for sure, and potentially annoying, but it won't outright break
> > anything), I suppose the worst case is too *few* automatic rebuilds, right? So
> > to me it sounds like you want to throw out the feature altogether because it
> > won't *always* catch everything. Or what potential bugs are you thinking about
> > that aren't useless rebuilds? I don't remember any from this thread, but of
> > course I could have missed something.
> 
> 
> 
> I too see your viewpoint, as you see mine. There's nothing wrong with
> your logic within the narrow domain of making the code that implements
> this specific feature (subslots) work correctly per spec.
> 
> Background: I'm a Linux sysadmin by day at an ISP. I constantly have to
> contend with Devs and Devops writing bespoke code to implement business
> rules. Because I sit three feet back from the problem, I can almost
> always see the flaws with the solution. I can't give much details
> unfortunately, my employer owns the code. But I get to be very very good
> at spotting code that runs per spec, but is very brittle in the real
> world. I look for tells like this:

For clarification: my background is very different and lies in science and
engineering, which has its own (overlapping) set of programming problems, some
of them probably (hopefully? (for you I mean)) of a more basic nature than what
you have to deal with.

One word: MATLAB. The only thing I'll say about it is that it's the only
programming language I know whose usage can make me aggressive (and I like POSIX
Shell, which at worst irritates me, so I think that's saying something). At
least I was able to choose the language used for my master's thesis myself
(Python, of course).

> - is the dev trying to get code deployed that is not fully tested?
> - is the dev trying to ignore or minimize the real world effect on other
> systems?
> - can the dev show that someone else (not him) can actually maintain it,
> configure it and understand it?
> - Can every single person in his team rattle off the primary salient
> points of the code without thinking much?
> - Did the team who write the code write a doc on how to configure it,
> and how to deal with possible failures they anticipate?
> - If someone else (like eg me) gets this wrong and I make mistakes while
> deploying, how will I know I've made a mistake? Do I get a sane error
> message that a) describes the error in simple language and b) does not
> make the fatal mistake of exposing the underlying implementation in
> error messages?
> - Do I need to read the code itself to gain even a high level
> understanding of what the code does?

Those sound like some pretty sane metrics, especially for important
infrastructure code. Also: anyone can code to spec, you just have to fix the
spec ;) .

One of those questions stands out to me right now: the one on understandable
error messages. As some recent posts to this ML demonstrate, it seems to be one
area where portage is visibly falling (staying?) behind right now. They remind
me of the type of error message gcc/g++ spit out, actually.

> By now you will have guessed that nearby Dev team hate my guts with a
> passion. Unlucky for them, I'm root and they ain't. Lucky for them, I'm
> quite reasonable and happy to work together to get the questions
> answered. With an answer of some kind, we can assess risk and make a
> rational choice. Oftentimes it comes down to we write one detailed
> technical doc and allay all fears.

Haha, yes, I bet they do hate your guts ;) .

However, in all honesty, I actually think having somebody perform a job like
that is a good thing. Mostly I think it boils down to the idea that writing
code in a cave (or echo chamber, for that matter) with no outside input will
pretty much never yield the best results (for a variety of reasons). Or put
differently: you should always seek external feedback on your code, if only to
get some outside perspective.

In fact, at my previous job at a local research institution my supervisor (sort
of) fulfilled such a role. However, he was pretty much alone in trying to
establish good (or at least *consistent*) programming practices and had little
power to enforce them. I would love to name some of the nastier examples of
what people would do (you know, apart from not writing proper build systems or
documentation, etc.), but I don't want to veer too much off topic.

> I don't see these questions being answered wrt subslots. Maybe they were
> answered and I haven't seen the link yet, maybe not. Maybe senior devs
> with clue have thus far successfully modified ebuilds, maybe not. Maybe
> more junior devshave yet to take their first steps, and maybe they will
> royally screw things up by not understanding the syntax, or maybe not.
> 
> These questions have not been answered and I certainly don't have
> answers; I also think neither do you. I would like to see this feature
> extensively tested in de and stage before it hits production. Only then
> can I decide for myself if subslots are a good solution to the stated
> problem.
> 
[...]

Yes, of course I don't have answers :) . I'm just a user thinking out loud and
sharing my experience.

Anyway, now that you've made your point clear as day, I see it better now :) .

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: do subslots improve user-experience?

[Martin Vaeth]

Marc Joliet <marcec@gmx.de> wrote:
>
> One of those questions stands out to me right now: the one on understandable
> error messages. As some recent posts to this ML demonstrate, it seems to
> be one area where portage is visibly falling (staying?) behind right now.
> They remind me of the type of error message gcc/g++ spit out, actually.

In both cases, it is technically very cumbersome to get good
error messages. In fact, it would need alone more work in programming
than to do the actual job (and it would slow down execution time
drastically even if no errors arise).

Concerning portage, the situation is apparently this
(I am guessing this only from the outputs which are posted):

When portage detects that it cannot resolve something after
backtracking, it dies. Then all non-resolved conflicts are
spit out - often these are some that *could* be resolved.
So instead of dying, portage would need to try to continue
to resolve anyway partially as far as it could and only then
die. This would mean that branches cannot be cut, so the runtime
would probably increase tremendously. Moreover, the result might
be even more confusing if there is some strange branch in which
slightly more resolving is possible.

Re: [gentoo-user] Re: do subslots improve user-experience?

[Alan McKinnon]

On 06/11/2013 14:54, Martin Vaeth wrote:
> Marc Joliet <marcec@gmx.de> wrote:
>>
>> One of those questions stands out to me right now: the one on understandable
>> error messages. As some recent posts to this ML demonstrate, it seems to
>> be one area where portage is visibly falling (staying?) behind right now.
>> They remind me of the type of error message gcc/g++ spit out, actually.
> 
> In both cases, it is technically very cumbersome to get good
> error messages. In fact, it would need alone more work in programming
> than to do the actual job (and it would slow down execution time
> drastically even if no errors arise).
> 
> Concerning portage, the situation is apparently this
> (I am guessing this only from the outputs which are posted):
> 
> When portage detects that it cannot resolve something after
> backtracking, it dies. Then all non-resolved conflicts are
> spit out - often these are some that *could* be resolved.
> So instead of dying, portage would need to try to continue
> to resolve anyway partially as far as it could and only then
> die. This would mean that branches cannot be cut, so the runtime
> would probably increase tremendously. Moreover, the result might
> be even more confusing if there is some strange branch in which
> slightly more resolving is possible.

That by itself is good info.

The conflict that portage couldn't resolve, is it the first one in the
printed list, or the last? This helps tell us what bits we can ignore at
least until the next emerge run


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: do subslots improve user-experience?

[Martin Vaeth]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 06/11/2013 14:54, Martin Vaeth wrote:
>> (I am guessing this only from the outputs which are posted):
>>
>> When portage detects that it cannot resolve something after
>> backtracking, it dies.
>
> That by itself is good info.
>
> The conflict that portage couldn't resolve, is it the first one in the
> printed list, or the last?

I never looked at the algorithm, it is only a guess from the output.
So I do no know the answer, and it does not matter, because every
conflict which portage detects might be related to the actual cause
or not: The algorithm with branch-cutting did not resolve the conflict,
so every inconsistency which is left might or might not be related
to the real obstacle which the user wants to remove.
Most likely this obstacle is higher in the tree than the place where
the conflict occurs (otherwise portage could resolve it or make
a suggestion how to resolve it).
In my experience, something related with the actual obstacle occurs
rather late in the output or not at all.

[gentoo-user] Re: do subslots improve user-experience?

[Martin Vaeth]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> It seems to me that you didn't read the whole post fully, and have
> cherry-picked a part that you think bolsters your position.

I do not think that I have a position here.
Subslots solve some problem.  If they cause inconveniences
like portage needing too long or frequent reemerges,
these issues should be attacked separately.

> I've run emerge -e world with the result of correcting something perhaps
> 2 or 3 times in 8 years.

You *realized* the necessity 2-3 times in 8 years.
For a production system one usually does not want an unrecognized
breakage ever.

> In effect subslots appear to fix something for me about once a year.

Given that on a production system you would have something
seriously broken once a year which is not the case with
subslots, I would say they have reached their goal.

> So now we have a rather large complex system

It is not complex at all: Except taking the dependency string
directly from the metadata it is before modified with information
from /var/db, and during merging the corresponding information
is stored in /var/db. Nothing magic is going on.

I think there is mainly a perception problem:
Whenever there is a problem with dependencies now subslots
are blamed, because they are shown by portage first.
In my experience, all these problems were just "usual" dependency
problems which just happen from to time and will always happen -
not related with subslots at all.

> Consider for a moment the maintenance burden imposed on ebuild
> maintainers

If your package provides a library and you bump the version
you also bump the subslot except if you happen to know for
sure that the library remains ABI-compatible. If you are short
on time this is a matter of seconds, if you are more careful
and want to do an excellent work you can remember
upstream's policy to save the user from an unnecessary rebuild.

> and how sub-slot notation is essentially added by humans
> deploying human brains. And remember that humans are notoriously bad at
> using mathematically correct solutions (they ... err ... forget to do
> stuff).

Yes, somebody might make a mistake and forget to bump
or do an unnecessary bump. So what? All sort of
mistakes can happen everywhere which can lead to all sort
of problems.

> I predict once a week fallout from sub-slots induced bugs that was
> intended to fix once a year problem.

Let's see: Forgetting to bump a subslot means that the purpose of
subslots for that package fails. A problem, but not worse than
without subslots. Bumping unnecessarily means that perhaps some
packages are rebuilt unnecessarily. Also not something dramatic.
Even if this *should* happen once a week (which I strongly doubt;
more realistic is once in a few months) nothing dramatic happens.

Re: [gentoo-user] Re: do subslots improve user-experience?

[Alan McKinnon]

On 05/11/2013 20:06, Martin Vaeth wrote:
>> I predict once a week fallout from sub-slots induced bugs that was
>> > intended to fix once a year problem.
> Let's see: Forgetting to bump a subslot means that the purpose of
> subslots for that package fails. A problem, but not worse than
> without subslots. Bumping unnecessarily means that perhaps some
> packages are rebuilt unnecessarily. Also not something dramatic.
> Even if this *should* happen once a week (which I strongly doubt;
> more realistic is once in a few months) nothing dramatic happens.
> 
> 

Why am I still feeling that I am not being understood correctly?

You don't have to keep explaining subslots to me, I understand how they
work and what they aim to accomplish:

DEPEND is a forward dependency and cannot deal with reverse
dependencies. Subslots provide the information to portage to be able to
deal with reverse dependencies when generating the dep graph. It does
not do it by interrogating the live filesystem or by discovery, it does
it by using metadata added to the ebuild by a human.

I know that if subslots are correctly defined throughout the tree,
rebuilds will happen during the emerge, and a later @preserved-rebuild
or revdep-rebuild will in all likelihood return null. I have no problem
with any of that, so there's no need to justify those claims further.

What I have maintained all along is that I don't see the solution as
tested to be production-ready and no-one has definitively stated what
can happen when a junior dev gets it spectacularly wrong. This may or
may not turn out to be a real problem in real life , but it is an
anticipated one that deserves an answer.

Keep in mind the real world nature of what a bug usually turns out to
be: something the dev did not anticipate (actual code flaws being
comparatively rare)


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: do subslots improve user-experience?

[Martin Vaeth]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> You don't have to keep explaining subslots to me

But not every reader knows the details - this is not a private
conversation.

> What I have maintained all along is that I don't see the solution as
> tested to be production-ready

It has been in ~arch for many months, and now it is becoming stable.
This is how testing works in gentoo.
As I tried to explain, even if devs do it wrong, there is not much
harm which can happen except for useless rebuilds or that the
advantage of subslots is missed by mistake.

In practice, it turns out that the portage error messages tend to
confuse users more now: The reason being that, although portage
would be able to resolve subslot dependencies automatically,
it does not show the resolved ones if it breaks before because of
an error, and so users see a lot of errors which actually are none
but occur only as a side effect of a completely different problem.
Although this behavior of portage happens not only for subslots,
the number of "false positives" has increased due to subslots.
This leads to the wrong perceiption which one can see in the forums.
  But misleading error messages due to non-finished resolving
were a problem which existed also before in portage and which
should be attacked anyway, if it can be.

Re: [gentoo-user] Re: do subslots improve user-experience?

[Alan McKinnon]

On 06/11/2013 09:46, Martin Vaeth wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>
>> You don't have to keep explaining subslots to me
> 
> But not every reader knows the details - this is not a private
> conversation.


Then please start your own thread on the matter and describe it all in
the OP rather than replying to me in public answering a question I did
not ask.

Thank you


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: do subslots improve user-experience?

[Martin Vaeth]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 06/11/2013 09:46, Martin Vaeth wrote:
>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>
>>> You don't have to keep explaining subslots to me
>>
>> But not every reader knows the details - this is not a private
>> conversation.
>
> Then please [...] describe it all in the OP rather than replying
> to me in public answering a question I did not ask.

Then do not make strange claims like mumbling about an
tremendous increase of complexity for developers which
just call for a clarification of the actual truth.
If you really know all the details about subslots, it
is rather strange that you make such claims.

Re: [gentoo-user] do subslots improve user-experience?

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/02/2013 07:04 AM, hasufell wrote:
> Another round of questioning the users here.
> 
> more specifically: * how often do you experience useless rebuilds? 
> * do you really have a problem with running 
> revdep-rebuild/haskell-updater/perl-cleaner etc after every
> emerge? * do you think it's worth the effort to add more stuff to
> the PM, so that you don't have to run revdep-rebuild that often? *
> do you trust the other methods like subslots or preserved-rebuild
> to work reliably? (as in: do you still use revdep-rebuild?)
> 
> If you want my opinion on subslots: # grep EMERGE_DEFAULT_OPTS
> /etc/portage/make.conf 
> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
> 
To be honest, I don't know what subslots are or what they do. Regular
slots allow for multiple versions of a package to coexist, right?
Using context and knowledge of English, a subslot tells me that it'd
be a second level of slotting, which I see limited use for. It'd be
most useful for development languages that have multiple subversions.

In short, subslots don't seem to be visible enough for me to give an
opinion on them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSdRr5AAoJEJUrb08JgYgHlEgH+QF954wvjrHPt15KBVuFHt1Q
AOSWYmtZJFEDi/xiIpMi6a36fcyV7NY/G6jUqq7MmcGf/vW4hHOxn25cqYJd4dZB
Ausb4TcAp9l86LsMdlVEJ+W4IBBVRgDnylD6TM9nUahSwwt/zQ4LzaLnbOW+V9F6
Rozj9VaXbYR5P4rfMHUK6ojZGpEtirTaaAFmmvuQH0ZkjEZzJVJqKwOxzIwIq1mf
9AUnO9cRJpXHE23xxDJ0YXQ8PZxvPnUBjQFXKj2XPoGm67bljK+3LVC9iPDQ5mLw
sL5sKe83GkQK+VtxXv3MvcLi4pExJaKbPVXscsaeDbXElXYvDc6a0X7snjA0YGQ=
=ki5a
-----END PGP SIGNATURE-----

Re: [gentoo-user] do subslots improve user-experience?

[Dustin C. Hatch]

On 11/2/2013 07:04, hasufell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Another round of questioning the users here.
These are good, thank you. Short answer here is no.

>
> more specifically:
> * how often do you experience useless rebuilds?
At least one of my machines is constantly wanting to rebuild some 
package or another. Currently, one of my desktops wants to rebuild 
x11-misc/compton with every emerge.

> * do you really have a problem with running
> revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?
No, because I typically understand when they're needed and can predict 
when I should use them, which really isn't all that often.

> * do you think it's worth the effort to add more stuff to the PM, so
> that you don't have to run revdep-rebuild that often?
I think we should have stopped at @preserved-rebuild. It's a sort of 
middle ground between rebuilding things all the time and having a broken 
system. I like it because it allows me to leave some things in a 
semi-broken state until I have time and CPU cycles to dedicate to 
rebuild them (i.e. libreoffice, etc.).

> * do you trust the other methods like subslots or preserved-rebuild to
> work reliably? (as in: do you still use revdep-rebuild?)
I've been using preserved-rebuild ever since it was backported to 2.1, 
and I don't think I've needed revdep-rebuild since then. I run it 
occasionally, but it's never found anything.

>
> If you want my opinion on subslots:
> # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
I'm getting closer to this sentiment as well; I'm beginning to think 
they're more trouble than they're worth. I'm getting tired of seeing an 
emerge list of 10 or 15 rebuilds when I'm trying to install something 
brand new because some package in the tree I already have installed has 
changed. If I cared about that package and its dependencies, I would 
have asked for it to be rebuilt/upgraded/whatever, but I don't, I'm 
working on something else right now.

-- 
♫Dustin
http://dustin.hatch.name/

Re: [gentoo-user] do subslots improve user-experience?

[Daniel Frey]

On 11/02/2013 05:04 AM, hasufell wrote:
> Another round of questioning the users here.
> 
> more specifically:
> * how often do you experience useless rebuilds?

A few times a year. To put this in perspective, I try to do major
updates (-uDN world) once a month. I used to do this weekly but can't
now due to time constraints. I find once a month is not too long - still
updateable without headaches caused by waiting half a year or more...

> * do you really have a problem with running
> revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?

Nope, although I use @preserved-rebuild more.

> * do you think it's worth the effort to add more stuff to the PM, so
> that you don't have to run revdep-rebuild that often?

> * do you trust the other methods like subslots or preserved-rebuild to
> work reliably? (as in: do you still use revdep-rebuild?)

I still use RR after a major update as it occasionally picks up
something that @preserved-rebuild misses. Last time it happened was a
month ago, but I can't recall the package, it was something to do with
multimedia, like libass or similar (on one of my mythtv frontends.)

Dan

Re: [gentoo-user] do subslots improve user-experience?

[Volker Armin Hemmann]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

Am 02.11.2013 13:04, schrieb hasufell:
> Another round of questioning the users here.
>
> more specifically:
> * how often do you experience useless rebuilds?

once every couple of updates?

> * do you really have a problem with running
> revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?

no, never had.

> * do you think it's worth the effort to add more stuff to the PM, so
> that you don't have to run revdep-rebuild that often?

if that makes portage even slower: no, I don't think it is worth the effort.

> * do you trust the other methods like subslots or preserved-rebuild to
> work reliably? (as in: do you still use revdep-rebuild?)

I haven't used revdep-rebuilt in a while, since preserved-rebuild works
fine.
Or let me phrase it differently: when a libpng update turned konqueror
is a complete crashfest NEITHER preserved-rebuild NOR revdep-rebuild did
anything about it. Only reading the error message and a lot of thinking,
followed by manual interference solved the problem - until the next
minor libpng-bump sent me back to hell.

>
> If you want my opinion on subslots:
> # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
>
> .
>



[-- Attachment #2: Type: text/html, Size: 1960 bytes --]

Re: [gentoo-user] do subslots improve user-experience?

[thegeezer]

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

On 11/02/2013 12:04 PM, hasufell wrote:
> Another round of questioning the users here.
>
> more specifically:
> * how often do you experience useless rebuilds?
not enough to notice, mostly using server based installs not desktop
> * do you really have a problem with running
> revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?
only ever used to run revdep rebuild if things were broken, and while
now i'm a little more aware of this kind of thing suddenly finding that
x program doesn't work due to bad library can be scary; especially if
you rely on x program.  preserved build was a genius idea if you ask me
as this at least allows things to continue working
> * do you think it's worth the effort to add more stuff to the PM, so
> that you don't have to run revdep-rebuild that often?
with preserved rebuild there is at least notification that revdep
rebuild is needed; as a noob i didn't realise the significance of the
program quite so much, expecting portage to just take care of dependencies.
> * do you trust the other methods like subslots or preserved-rebuild to
> work reliably? (as in: do you still use revdep-rebuild?)
>
subslots to me just work like magic and i'm content for the moment to
allow them to remain a mystery to me.  looking at other responses i'm
glad i'm not the only one(!) i get it on the surface but have never
played with them so don't fully understand.   as i said earlier
preserved rebuild is great because a) you get notification of
revdeprebuild requirement and b) things don't break after upgrade
> If you want my opinion on subslots:
> # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
>
/me politely requests more info and goes to google to find some too


[-- Attachment #2: Type: text/html, Size: 2459 bytes --]

Re: [gentoo-user] do subslots improve user-experience?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

On Sat, 02 Nov 2013 13:04:52 +0100, hasufell wrote:

> * how often do you experience useless rebuilds?

That's an unreasonable question. How do we know whether a rebuild was
useless or not unless we skip it and then find that a single feature of a
complex program no longer works properly, and to do that we have to block
the update from emerge world.

Yes, there are a lot more updates and rebuilds, but are these useless? I
have no facts to device either way.

> * do you really have a problem with running
> revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?

No. The only problem with those approaches is knowing when they need to be
run. That's what I like about the preserved-rebuild approach, it tells
you that rebuilds need to be done but lets the user device when to do
them.

> * do you think it's worth the effort to add more stuff
> to the PM, so that you don't have to run revdep-rebuild that often?

If it's done in a way that is understandable to users. Gentoo users like,
even need, to understand what is going on. Sub-slots don't achieve that.

> * do you trust the other methods like subslots or preserved-rebuild to
> work reliably? (as in: do you still use revdep-rebuild?)

I trust preserved-rebuild. I have a weekly cron script that checks
various aspects of my system, including a revdep-rebuild -p. That part
almost never finds anything these days.

Sub-slots appear to work, but they are opaque and intrusive.
@preserved-rebuild requires a tiny amount more effort from the user, but
gives more control and seems more Gentoo-ish to me.


-- 
Neil Bothwick

Q:  Why is top-posting evil?
A: backwards read don't humans because

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: do subslots improve user-experience?

[walt]

On 11/02/2013 02:26 PM, Neil Bothwick wrote:

> I have no facts to device either way.
<snip>
> but lets the user device when to do them.

Neil, are you using a new auto-complete function of some kind?

Re: [gentoo-user] Re: do subslots improve user-experience?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On Sat, 02 Nov 2013 17:38:00 -0700, walt wrote:

> > I have no facts to device either way.  
> <snip>
> > but lets the user device when to do them.  
> 
> Neil, are you using a new auto-complete function of some kind?

Yes, it's called sleep deprivation :(


-- 
Neil Bothwick

"We can't solve problems by using the same kind of thinking we used when
we created them." (Albert Einstein)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] do subslots improve user-experience?

[Bruce Hill]

On Sat, Nov 02, 2013 at 01:04:52PM +0100, hasufell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Another round of questioning the users here.
> 
> more specifically:
> * how often do you experience useless rebuilds?
> * do you really have a problem with running
> revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?
> * do you think it's worth the effort to add more stuff to the PM, so
> that you don't have to run revdep-rebuild that often?
> * do you trust the other methods like subslots or preserved-rebuild to
> work reliably? (as in: do you still use revdep-rebuild?)
> 
> If you want my opinion on subslots:
> # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"

This kind of subslot mess is so irritating:

workstation ~ # emerge -aDjtuv --changed-use @world && dispatch-conf && emerge -a --depclean && revdep-rebuild -i && clear && exit

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild  rR    ] dev-qt/qtgui-4.8.5-r1:4  USE="accessibility exceptions glib xv (-aqua) -cups -debug -egl -gtkstyle -mng -nas -nis -pch -qt3support -tiff -trace -xinerama" 0 kB
[ebuild  rR    ] media-libs/libwebp-0.3.1  USE="jpeg png -experimental -gif -opengl -static-libs -swap-16bit-csp -tiff" ABI_X86="(64) (-32) (-x32)" 0 kB
[ebuild  rR    ] app-emulation/wine-1.6  USE="X alsa cups fontconfig jpeg mono mp3 ncurses nls opengl perl png prelink run-exes ssl threads truetype udisks xml -capi -custom-cflags -dos -gecko -gphoto2 -gsm -gstreamer -lcms -ldap -odbc -openal -opencl -osmesa -oss -pulseaudio -samba -scanner (-selinux) {-test} -v4l -xcomposite -xinerama" ABI_X86="32 64 (-x32)" LINGUAS="en_US -ar -bg -ca -cs -da -de -el -en -eo -es -fa -fi -fr -he -hi -hr -hu -it -ja -ko -lt -ml -nb_NO -nl -or -pa -pl -pt_BR -pt_PT -rm -ro -ru -sk -sl -sr_RS@cyrillic -sr_RS@latin -sv -te -th -tr -uk -wa -zh_CN -zh_TW" 0 kB
[ebuild     U ~] www-client/firefox-25.0-r1 [24.0-r1] USE="alsa dbus jit libnotify startup-notification -bindist -custom-cflags -custom-optimization -debug -gstreamer -minimal (-pgo) -pulseaudio (-selinux) -system-cairo -system-icu -system-jpeg -system-sqlite -wifi" LINGUAS="-af -ak -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -csb -cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko -ku -lg -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -nso -or -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -ta_LK -te -th -tr -uk -vi -zh_CN -zh_TW -zu" 124,545 kB
[ebuild     U  ] app-portage/pfl-2.4-r1 [2.3] USE="network-cron" PYTHON_TARGETS="python2_7%* -python2_6%" 7 kB
[ebuild     U ~] mail-client/thunderbird-24.1.0-r1 [24.0-r1] USE="alsa dbus jit libnotify lightning startup-notification -bindist -crypt -custom-cflags -custom-optimization -debug -gstreamer -ldap -minimal -mozdom -pulseaudio (-selinux) -system-cairo -system-icu -system-jpeg -system-sqlite -wifi" LINGUAS="-ar -ast -be -bg -bn_BD -br -ca -cs -da -de -el -en_GB -es_AR -es_ES -et -eu -fi -fr -fy_NL -ga_IE -gd -gl -he -hr -hu -hy_AM -id -is -it -ja -ko -lt -nb_NO -nl -nn_NO -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -sq -sr -sv_SE -ta_LK -tr -uk -vi -zh_CN -zh_TW" 137,057 kB
[ebuild  rR    ] net-print/cups-filters-1.0.36-r1  USE="jpeg png tiff -perl -static-libs -zeroconf" 0 kB
[ebuild  rR    ]  app-text/poppler-0.24.3:0/43  USE="cairo cjk cxx introspection jpeg jpeg2k lcms png tiff utils -curl -debug -doc -qt4" 0 kB
[ebuild  rR    ]   media-libs/openjpeg-1.5.1  USE="-doc -static-libs {-test}" 0 kB
[ebuild  rR    ]   x11-libs/cairo-1.12.14-r4  USE="X glib svg (-aqua) -debug -directfb -doc (-drm) (-gallium) (-gles2) -legacy-drivers -opengl -openvg (-qt4) -static-libs -valgrind -xcb -xlib-xcb" 0 kB
[ebuild  r  U ~]    media-libs/libpng-1.6.6:0/16 [1.5.15:0/0] USE="apng (-neon) -static-libs" ABI_X86="(64%*) -32% (-x32)" 860 kB

Total: 11 packages (4 upgrades, 7 reinstalls), Size of downloads: 262,467 kB

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by @__auto_slot_operator_replace_installed__ (argument)
=media-libs/libpng-1.6.6 ~amd64

Use --autounmask-write to write changes to config files (honoring
CONFIG_PROTECT). Carefully examine the list of proposed changes,
paying special attention to mask or keyword changes that may expose
experimental or unstable packages.

!!! The following installed packages are masked:
- net-analyzer/mtr-0.82::gentoo (masked by: package.mask)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

workstation ~ # grep libpng /usr/portage/net-print/cups-filters/cups-filters-1.0.36-r1.ebuild 
	png? ( media-libs/libpng:0= )
workstation ~ # grep libpng /usr/portage/app-text/poppler/poppler-0.24.3.ebuild 
	png? ( media-libs/libpng:0= )     
workstation ~ # grep libpng /usr/portage/media-libs/openjpeg/openjpeg-1.5.1.ebuild 
	media-libs/libpng:0=[static-libs?]
workstation ~ # grep libpng /usr/portage/x11-libs/cairo/cairo-1.12.14-r4.ebuild 
	media-libs/libpng:0=
	epatch "${FILESDIR}"/${PN}-1.12.14-libpng16.patch
workstation ~ # eshowkw media-libs/libpng
Keywords for media-libs/libpng:
             |                           | u      |  
             | a a             p     s   | n      |  
             | l m   h i m m   p s   p   | u s    | r
             | p d a p a 6 i p c 3   a x | s l    | e
             | h 6 r p 6 8 p p 6 9 s r 8 | e o    | p
             | a 4 m a 4 k s c 4 0 h c 6 | d t    | o
-------------+---------------------------+--------+-------
   1.2.50    | ~ + + ~ + + ~ o + + + + + | o 1.2  | gentoo
   1.2.50-r1 | ~ ~ ~ ~ ~ ~ ~ o ~ ~ ~ ~ ~ | o      | gentoo
-------------+---------------------------+--------+-------
[I]1.5.15    | + + + + + ~ ~ + + + + + + | o 0    | gentoo
-------------+---------------------------+--------+-------
   1.5.17    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o 1.5  | gentoo
-------------+---------------------------+--------+-------
    1.6.6    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o 0/16 | gentoo
workstation ~ # grep libpng /etc/portage/package.*
/etc/portage/package.use:media-libs/libpng apng



Just whomever decided to add the 16 subslot caused libpng ~amd64 to be pulled
for those amd64 packages. Gentoo has a long history of libpng ~amd64 problems.
What is the need for the stinking 0/16 subslot here? What was it not good
enough to slot 1.6.6 as 1.6?

And with this *new* subslotting, what is The Gentoo Way (TM) to keep stable
libpng in this instance?

Cheers,
Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] do subslots improve user-experience?

[Bruce Hill]

On Tue, Nov 05, 2013 at 07:29:28AM -0600, Bruce Hill wrote:
> On Sat, Nov 02, 2013 at 01:04:52PM +0100, hasufell wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Another round of questioning the users here.
> > 
> > more specifically:
> > * how often do you experience useless rebuilds?
> > * do you really have a problem with running
> > revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge?
> > * do you think it's worth the effort to add more stuff to the PM, so
> > that you don't have to run revdep-rebuild that often?
> > * do you trust the other methods like subslots or preserved-rebuild to
> > work reliably? (as in: do you still use revdep-rebuild?)
> > 
> > If you want my opinion on subslots:
> > # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
> > EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
> 
> This kind of subslot mess is so irritating:
> 
> workstation ~ # emerge -aDjtuv --changed-use @world && dispatch-conf && emerge -a --depclean && revdep-rebuild -i && clear && exit
> 
> These are the packages that would be merged, in reverse order:
> 
> Calculating dependencies... done!
> [ebuild  rR    ] dev-qt/qtgui-4.8.5-r1:4  USE="accessibility exceptions glib xv (-aqua) -cups -debug -egl -gtkstyle -mng -nas -nis -pch -qt3support -tiff -trace -xinerama" 0 kB
> [ebuild  rR    ] media-libs/libwebp-0.3.1  USE="jpeg png -experimental -gif -opengl -static-libs -swap-16bit-csp -tiff" ABI_X86="(64) (-32) (-x32)" 0 kB
> [ebuild  rR    ] app-emulation/wine-1.6  USE="X alsa cups fontconfig jpeg mono mp3 ncurses nls opengl perl png prelink run-exes ssl threads truetype udisks xml -capi -custom-cflags -dos -gecko -gphoto2 -gsm -gstreamer -lcms -ldap -odbc -openal -opencl -osmesa -oss -pulseaudio -samba -scanner (-selinux) {-test} -v4l -xcomposite -xinerama" ABI_X86="32 64 (-x32)" LINGUAS="en_US -ar -bg -ca -cs -da -de -el -en -eo -es -fa -fi -fr -he -hi -hr -hu -it -ja -ko -lt -ml -nb_NO -nl -or -pa -pl -pt_BR -pt_PT -rm -ro -ru -sk -sl -sr_RS@cyrillic -sr_RS@latin -sv -te -th -tr -uk -wa -zh_CN -zh_TW" 0 kB
> [ebuild     U ~] www-client/firefox-25.0-r1 [24.0-r1] USE="alsa dbus jit libnotify startup-notification -bindist -custom-cflags -custom-optimization -debug -gstreamer -minimal (-pgo) -pulseaudio (-selinux) -system-cairo -system-icu -system-jpeg -system-sqlite -wifi" LINGUAS="-af -ak -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -csb -cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko -ku -lg -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -nso -or -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -ta_LK -te -th -tr -uk -vi -zh_CN -zh_TW -zu" 124,545 kB
> [ebuild     U  ] app-portage/pfl-2.4-r1 [2.3] USE="network-cron" PYTHON_TARGETS="python2_7%* -python2_6%" 7 kB
> [ebuild     U ~] mail-client/thunderbird-24.1.0-r1 [24.0-r1] USE="alsa dbus jit libnotify lightning startup-notification -bindist -crypt -custom-cflags -custom-optimization -debug -gstreamer -ldap -minimal -mozdom -pulseaudio (-selinux) -system-cairo -system-icu -system-jpeg -system-sqlite -wifi" LINGUAS="-ar -ast -be -bg -bn_BD -br -ca -cs -da -de -el -en_GB -es_AR -es_ES -et -eu -fi -fr -fy_NL -ga_IE -gd -gl -he -hr -hu -hy_AM -id -is -it -ja -ko -lt -nb_NO -nl -nn_NO -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -sq -sr -sv_SE -ta_LK -tr -uk -vi -zh_CN -zh_TW" 137,057 kB
> [ebuild  rR    ] net-print/cups-filters-1.0.36-r1  USE="jpeg png tiff -perl -static-libs -zeroconf" 0 kB
> [ebuild  rR    ]  app-text/poppler-0.24.3:0/43  USE="cairo cjk cxx introspection jpeg jpeg2k lcms png tiff utils -curl -debug -doc -qt4" 0 kB
> [ebuild  rR    ]   media-libs/openjpeg-1.5.1  USE="-doc -static-libs {-test}" 0 kB
> [ebuild  rR    ]   x11-libs/cairo-1.12.14-r4  USE="X glib svg (-aqua) -debug -directfb -doc (-drm) (-gallium) (-gles2) -legacy-drivers -opengl -openvg (-qt4) -static-libs -valgrind -xcb -xlib-xcb" 0 kB
> [ebuild  r  U ~]    media-libs/libpng-1.6.6:0/16 [1.5.15:0/0] USE="apng (-neon) -static-libs" ABI_X86="(64%*) -32% (-x32)" 860 kB
> 
> Total: 11 packages (4 upgrades, 7 reinstalls), Size of downloads: 262,467 kB
> 
> The following keyword changes are necessary to proceed:
>  (see "package.accept_keywords" in the portage(5) man page for more details)
> # required by @__auto_slot_operator_replace_installed__ (argument)
> =media-libs/libpng-1.6.6 ~amd64
> 
> Use --autounmask-write to write changes to config files (honoring
> CONFIG_PROTECT). Carefully examine the list of proposed changes,
> paying special attention to mask or keyword changes that may expose
> experimental or unstable packages.
> 
> !!! The following installed packages are masked:
> - net-analyzer/mtr-0.82::gentoo (masked by: package.mask)
> For more information, see the MASKED PACKAGES section in the emerge
> man page or refer to the Gentoo Handbook.
> 
> workstation ~ # grep libpng /usr/portage/net-print/cups-filters/cups-filters-1.0.36-r1.ebuild 
> 	png? ( media-libs/libpng:0= )
> workstation ~ # grep libpng /usr/portage/app-text/poppler/poppler-0.24.3.ebuild 
> 	png? ( media-libs/libpng:0= )     
> workstation ~ # grep libpng /usr/portage/media-libs/openjpeg/openjpeg-1.5.1.ebuild 
> 	media-libs/libpng:0=[static-libs?]
> workstation ~ # grep libpng /usr/portage/x11-libs/cairo/cairo-1.12.14-r4.ebuild 
> 	media-libs/libpng:0=
> 	epatch "${FILESDIR}"/${PN}-1.12.14-libpng16.patch
> workstation ~ # eshowkw media-libs/libpng
> Keywords for media-libs/libpng:
>              |                           | u      |  
>              | a a             p     s   | n      |  
>              | l m   h i m m   p s   p   | u s    | r
>              | p d a p a 6 i p c 3   a x | s l    | e
>              | h 6 r p 6 8 p p 6 9 s r 8 | e o    | p
>              | a 4 m a 4 k s c 4 0 h c 6 | d t    | o
> -------------+---------------------------+--------+-------
>    1.2.50    | ~ + + ~ + + ~ o + + + + + | o 1.2  | gentoo
>    1.2.50-r1 | ~ ~ ~ ~ ~ ~ ~ o ~ ~ ~ ~ ~ | o      | gentoo
> -------------+---------------------------+--------+-------
> [I]1.5.15    | + + + + + ~ ~ + + + + + + | o 0    | gentoo
> -------------+---------------------------+--------+-------
>    1.5.17    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o 1.5  | gentoo
> -------------+---------------------------+--------+-------
>     1.6.6    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o 0/16 | gentoo
> workstation ~ # grep libpng /etc/portage/package.*
> /etc/portage/package.use:media-libs/libpng apng
> 
> 
> 
> Just whomever decided to add the 16 subslot caused libpng ~amd64 to be pulled
> for those amd64 packages. Gentoo has a long history of libpng ~amd64 problems.
> What is the need for the stinking 0/16 subslot here? What was it not good
> enough to slot 1.6.6 as 1.6?
> 
> And with this *new* subslotting, what is The Gentoo Way (TM) to keep stable
> libpng in this instance?

I didn't check that www-client/firefox-25.0-r1 was actually requiring
>=media-libs/libpng-1.5.17[apng]

Why did -t (tree) not show www-client/firefox-25.0-r1 pulling libpng?

       --tree (-t)
              Shows the dependency tree for the given target by indenting dependencies.  This is only really useful in combination with --emptytree  or  --update  and
              --deep.

So I just masked www-client/firefox until stable libpng, that isn't itself
broken or introduced regressions, catches up. Gentoo's history with libpng
compels me to keep it arch. ;)

I can't understand the *need* for the new slot/subslot philosophy. In the
former methodology we would have:

workstation ~ # eshowkw media-libs/libpng
Keywords for media-libs/libpng:
             |                           | u      |  
             | a a             p     s   | n      |  
             | l m   h i m m   p s   p   | u s    | r
             | p d a p a 6 i p c 3   a x | s l    | e
             | h 6 r p 6 8 p p 6 9 s r 8 | e o    | p
             | a 4 m a 4 k s c 4 0 h c 6 | d t    | o
-------------+---------------------------+--------+-------
   1.2.50    | ~ + + ~ + + ~ o + + + + + | o 1.2  | gentoo
   1.2.50-r1 | ~ ~ ~ ~ ~ ~ ~ o ~ ~ ~ ~ ~ | o      | gentoo
-------------+---------------------------+--------+-------
[I]1.5.15    | + + + + + ~ ~ + + + + + + | o 1.5  | gentoo
   1.5.17    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o      | gentoo
-------------+---------------------------+--------+-------
    1.6.6    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o 1.6  | gentoo

What was the problem with this?
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] do subslots improve user-experience?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Tue, 5 Nov 2013 08:29:59 -0600, Bruce Hill wrote:

> I can't understand the *need* for the new slot/subslot philosophy.

The need to it is clear. Previous methods worked by breaking things and
then fixing them, hopefully before the breakage became a problem,
whenever library APIs changed. Subslots are an attempt to deal with this
proactively by fixing the problems as they occur.

Whether subslots are the best way to do it, and whether the
implementation is ideal, as separate questions, but there is no doubt
that any system that relies on the existence of revdep-rebuild is
seriously flawed.

To my mind, the question is not "are subslots needed" but "are they the
best solution to this problem".


-- 
Neil Bothwick

Most software is about as user-friendly as a cornered rat!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] do subslots improve user-experience?

[Bruce Hill]

On Tue, Nov 05, 2013 at 09:28:05PM +0000, Neil Bothwick wrote:
> On Tue, 5 Nov 2013 08:29:59 -0600, Bruce Hill wrote:
> 
> > I can't understand the *need* for the new slot/subslot philosophy.
> 
> The need to it is clear. Previous methods worked by breaking things and
> then fixing them, hopefully before the breakage became a problem,
> whenever library APIs changed. Subslots are an attempt to deal with this
> proactively by fixing the problems as they occur.
> 
> Whether subslots are the best way to do it, and whether the
> implementation is ideal, as separate questions, but there is no doubt
> that any system that relies on the existence of revdep-rebuild is
> seriously flawed.
> 
> To my mind, the question is not "are subslots needed" but "are they the
> best solution to this problem".

You misread my statement, also. It is in alignment with your last sentence.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting