[gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Hello.

The new "features" use.stable.mask and package.use.stable.mask
have turned maintaining systems with mixed ARCH and ~ARCH keywords
into a nightmare:

Similarly to the (fortunately dropped) concept of forcing
useflags if certain packages are installed this forces a
magic on the user which can hardly be managed since it is
not clearly presented to the user but hidden in some profiles.

As I understand, it tries to solve a "social" issue
(that an ARCH user might set a USE-flag which eventually
pulls in an ~ARCH package) on a technical level
(by forcibly disabling the USE-flag for the user).
Solving social problems by technical means is never a good
idea:

While the former gives the stable user a clear message
what is going wrong (after all, many stable users want
some package which has not a stable version yet, so this
should be something everybody should be able to handle),
the latter hides causes and makes things almost unpredictable:

Even if the user has put the dependency into
package.accept_keywords, he will not be able to use the
USE-flag on his packages unless
*he puts stable versions into package.accept_keywords*
(or - simlarly worse - overrides the profile).

The really bad thing is that this is happening by magic
"behind the user's back", i.e. contradicting the user's setting
of USE-flag and package.use: If the user does not carefully
read emerge's -v output, he even does not get informed that
the support for his unstable package is dropped from the
stable package, despite he might have specified the corresponding
USE-flag globally. Even worse, even when reading the output
carefully, the user cannot understand the reason:
Since there are many reasons why use-flags can appear in ()
he will probably not even conjecture that actually something
will not be working as he expected.

Here are some other examples of negative effects happening
just recently to me, ordered from not so severe to very bad:

1. For several reasons I always want the most current
emul-linux-x86* libraries, so they are in package.accept_keywords.
Due to global ABI_X86=32 (which I also want), this forced me
of course to put several libraries to ~amd64 since only
new version support this. Some of the libraries are actually
stable, so I have removed them from package.accept_keywords.
So far, so good.
But suddenly portage spitted unexplainable dependency errors,
and I only expert users manually reading the profiles can
understand that the reason is that use.stable.mask requires
that stable versions need to be keyworded ~amd64
(or use.stable.mask has to be overridden in my profile).

2. Just a few days ago dev-lang/python-exec:2 became stable
on amd64, but dev-python/python-exec:2 is still ~amd64.
Just to be sure to not miss anything, I have put the latter
into package.accept_keywords, and hell break loose:
Portaqe wanted me to emerge the git version of
dev-lang/python-exec:0 and reemerge dozens of packages.
I needed hours to find out what is the actual cause:
The package.accept_keywords caused the use.stable.mask of
python_targets_pypy2_0 und python_targets_python3_3 to become
ineffective for dev-python/python-exec, but of course it is still
effective for dev-lang/python-exec which is not be the case
if I unmask the git version of dev-lang/python-exec.

This is completely confusing since nowhere the git-version
is marked differently than the non-git version.

So, yes, portage's behaviour can be explained, but, no,
it is not understandable by a user who wants portage
to report what is really wrong and who does not want
to check manually by reading all profiles and hunt down
for reasons why certain flags are magically forced/disabled.

3. As a side effect of 2., I realized that libreoffice and a dozen
further packages get forced a rebuild. So, if eventually
python-3.3 becomes stable and is removed from use.stable.mask,
all stable users will have to rebuild almost their whole world,
because python-exec then has one more "dummy" USE-flag. The same
will happen again if pypy-2.0 becomes stable.
So a lot of unnecessary rebuilds happen to stable users because
of {package.,}use.stable.mask which most of the developers
(who are often ~amd64 users) do not realize.

Best Regards
Martin

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Wed, 13 Nov 2013 10:28:02 +0000 (UTC)
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:

> Hello.
> 
> The new "features" use.stable.mask and package.use.stable.mask
> have turned maintaining systems with mixed ARCH and ~ARCH keywords
> into a nightmare:

They are considered unsupported by many; so, going down that path you
need to be acquainted with Portage enough to keep a consistent system.

> Similarly to the (fortunately dropped) concept of forcing
> useflags if certain packages are installed this forces a
> magic on the user which can hardly be managed since it is
> not clearly presented to the user but hidden in some profiles.
> 
> As I understand, it tries to solve a "social" issue
> (that an ARCH user might set a USE-flag which eventually
> pulls in an ~ARCH package) on a technical level
> (by forcibly disabling the USE-flag for the user).

That's one approach, it might also be used when a package can be
stabilized but a certain of feature of the package cannot; eg.
USE="minimal" could be broken on a certain package because it removed a
bit too much, thus it could be stabilized with USE="-minimal" forced.

Anyhow, I think we should make sure to weight "why we need to have it"
against "how it bothers which users"; and not just focus on users alone.

And other than that, are there alternatives? Something we can do better?

Sometimes problems can be resolved by better communication too; perhaps
there are things we can inform the user about in pkg_postinst, or
improve Portage to let the user know of a particular forced USE flag.

> Solving social problems by technical means is never a good
> idea:
> 
> While the former gives the stable user a clear message
> what is going wrong (after all, many stable users want
> some package which has not a stable version yet, so this
> should be something everybody should be able to handle),
> the latter hides causes and makes things almost unpredictable:
> 
> Even if the user has put the dependency into
> package.accept_keywords, he will not be able to use the
> USE-flag on his packages unless
> *he puts stable versions into package.accept_keywords*
> (or - simlarly worse - overrides the profile).

That are indeed the two approaches, I don't see a problem with putting
the version itself in accept_keywords or overriding the profile;
furthermore, overriding forced and/or masked USE flag is the exception,
it doesn't happen so frequently so I doubt this is a huge problem.

> The really bad thing is that this is happening by magic
> "behind the user's back", i.e. contradicting the user's setting
> of USE-flag and package.use: If the user does not carefully
> read emerge's -v output, he even does not get informed that
> the support for his unstable package is dropped from the
> stable package, despite he might have specified the corresponding
> USE-flag globally.

System upgrades have to be done carefully; so, the user skipping it is
something we cannot account for except perhaps providing support for
the user receiving some kind of verbose summary of such forces / masks
being present at the end of the emerge output. But you'll have to
contact the Portage developers to achieve such improvements.

> Even worse, even when reading the output
> carefully, the user cannot understand the reason:
> Since there are many reasons why use-flags can appear in ()
> he will probably not even conjecture that actually something
> will not be working as he expected.

Most of these reasons can be uniquely determined from the output; but
indeed, some might yield the same output, but this is again something
that the Portage developers can improve and not a reason for removal.

> Here are some other examples of negative effects happening
> just recently to me, ordered from not so severe to very bad:
> 
> 1. For several reasons I always want the most current
> emul-linux-x86* libraries, so they are in package.accept_keywords.
> Due to global ABI_X86=32 (which I also want), this forced me
> of course to put several libraries to ~amd64 since only
> new version support this. Some of the libraries are actually
> stable, so I have removed them from package.accept_keywords.
> So far, so good.
> But suddenly portage spitted unexplainable dependency errors,
> and I only expert users manually reading the profiles can
> understand that the reason is that use.stable.mask requires
> that stable versions need to be keyworded ~amd64
> (or use.stable.mask has to be overridden in my profile).

This confuses me; isn't the goal to have one multilib apprach or the
other? Especially due to the blockers between them.

I agree Portage output can be better, I'm not sure if use.stable.mask
is really the problem here though; but rather the nature of mixing them.

> 2. Just a few days ago dev-lang/python-exec:2 became stable
> on amd64, but dev-python/python-exec:2 is still ~amd64.
> Just to be sure to not miss anything, I have put the latter
> into package.accept_keywords, and hell break loose:

Hell indeed breaks loose if you mix stable and unstable; but note that
this package had an accident, see the related news item for details.

> Portaqe wanted me to emerge the git version of
> dev-lang/python-exec:0 and reemerge dozens of packages.

This is a consequence of that hell; if you don't agree and this is due
to the Portage tree, please show the dependency chain that causes this.

> I needed hours to find out what is the actual cause:
> The package.accept_keywords caused the use.stable.mask of
> python_targets_pypy2_0 und python_targets_python3_3 to become
> ineffective for dev-python/python-exec,

It doesn't matter, dev-python/python-exec installs no contents.

> but of course it is still
> effective for dev-lang/python-exec which is not be the case
> if I unmask the git version of dev-lang/python-exec.

Which one is not meant to do anyway; and from what you wrote, I don't
think you intent to either.

> This is completely confusing since nowhere the git-version
> is marked differently than the non-git version.

Marked in which way? One is stable, the other unkeyworded.

> So, yes, portage's behaviour can be explained, but, no,
> it is not understandable by a user who wants portage
> to report what is really wrong and who does not want
> to check manually by reading all profiles and hunt down
> for reasons why certain flags are magically forced/disabled.

Which output are we discussing here?

If it is due to the hell above, we warn users up front for that.

> 3. As a side effect of 2., I realized that libreoffice and a dozen
> further packages get forced a rebuild. So, if eventually
> python-3.3 becomes stable and is removed from use.stable.mask,
> all stable users will have to rebuild almost their whole world,
> because python-exec then has one more "dummy" USE-flag. The same
> will happen again if pypy-2.0 becomes stable.
> So a lot of unnecessary rebuilds happen to stable users because
> of {package.,}use.stable.mask which most of the developers
> (who are often ~amd64 users) do not realize.

That is to be expected on such stabilizations, I doubt they are
unnecessary; if I misunderstood, feel free to give an example.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Thomas Kahle]

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

Hi,

On 11/13/2013 12:39 PM, Tom Wijsman wrote:
> On Wed, 13 Nov 2013 10:28:02 +0000 (UTC)
> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> 
>> Hello.
>>
>> The new "features" use.stable.mask and package.use.stable.mask
>> have turned maintaining systems with mixed ARCH and ~ARCH keywords
>> into a nightmare:
> 
> They are considered unsupported by many; so, going down that path you
> need to be acquainted with Portage enough to keep a consistent system.

This argument has come up several times, but is it valid?  For me
and other people I know, the main reason to use Gentoo is the
rolling release model and this implies that you can mix package
versions as long as version dependencies are satisfied.  When the
dependency is "cat/package" then this should mean that it works
with every version.  If it does not, then the ebuild's
dependencies should be updated.

The handbook says nothing about "unsupported":

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=3

If "many" choose to change this policy, there is no reason
anymore for me to use Gentoo.

>> Similarly to the (fortunately dropped) concept of forcing
>> useflags if certain packages are installed this forces a
>> magic on the user which can hardly be managed since it is
>> not clearly presented to the user but hidden in some profiles.
>>
>> As I understand, it tries to solve a "social" issue
>> (that an ARCH user might set a USE-flag which eventually
>> pulls in an ~ARCH package) on a technical level
>> (by forcibly disabling the USE-flag for the user).
> 
> That's one approach, it might also be used when a package can be
> stabilized but a certain of feature of the package cannot; eg.
> USE="minimal" could be broken on a certain package because it removed a
> bit too much, thus it could be stabilized with USE="-minimal" forced.
> 
> Anyhow, I think we should make sure to weight "why we need to have it"
> against "how it bothers which users"; and not just focus on users alone.
> 
> And other than that, are there alternatives? Something we can do better?

We could consider reducing the feature set of portage and live
with the "problems" that arise.  When I started using Gentoo a
package could simply not go stable until all dependencies for all
USE flags were also stable.  Masking USE flags was reserved to a
short list of very special architecture depend special cases.

[...]

>> 2. Just a few days ago dev-lang/python-exec:2 became stable
>> on amd64, but dev-python/python-exec:2 is still ~amd64.
>> Just to be sure to not miss anything, I have put the latter
>> into package.accept_keywords, and hell break loose:
> 
> Hell indeed breaks loose if you mix stable and unstable; but note that
> this package had an accident, see the related news item for details.

Do you mean stable and unstable in this case, or in general?

[...]

In general I share the sentiment.  The complexity of using
portage has increased a lot lately.  Not only does it take long
to find out why things suddenly go wrong after tree sync, also
just the time until 'emerge -avUDN world' comes back with a
proposal has grown to several minutes where it was few seconds
when I started with Gentoo.

There has been a lot of effort to make revdep-rebuild unessecary,
but now that it is mostly implemented, I don't know if it was
worth the price.  I spend more time now just reconfiguring
keywords to update the system than I spent back in the old days
where revdep would just fix things.  If the answer is, that I
should not mix arch and ~arch, then I'll not use Gentoo anymore.

Cheers,
Thomas


-- 
Thomas Kahle


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle <tomka@gentoo.org> wrote:
> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
>> On Wed, 13 Nov 2013 10:28:02 +0000 (UTC)
>> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
>>
>>> Hello.
>>>
>>> The new "features" use.stable.mask and package.use.stable.mask
>>> have turned maintaining systems with mixed ARCH and ~ARCH keywords
>>> into a nightmare:
>>
>> They are considered unsupported by many; so, going down that path you
>> need to be acquainted with Portage enough to keep a consistent system.
>
> This argument has come up several times, but is it valid?

Honestly, opinions vary on this one and I don't think it is a
productive path to go down.  I also feel that being able to mix
keywords is a big benefit of using Gentoo.  I'd rather focus on
practical ways to make this easier rather than whether it is
desirable.

That said, there are always going to be situations where mixing
keywords isn't practical.  You're not going to run stable chromium
against ~arch v8, or mixed keywords between kdelibs and kwin, etc.

> We could consider reducing the feature set of portage and live
> with the "problems" that arise.  When I started using Gentoo a
> package could simply not go stable until all dependencies for all
> USE flags were also stable.  Masking USE flags was reserved to a
> short list of very special architecture depend special cases.

I don't think going backwards is the solution.  Back in the old days
packages broke from time to time because we didn't have adequate ways
to express dependencies, and I don't think it is a good solution to
strip USE flags out of packages when they go stable so that users
don't even have the option to use them.

It makes more sense to identify what specifically is causing problems
and come up with better solutions to them.  That said, your original
email contained a few separate issues and they're probably best dealt
with individually.  We're not going to have a common solution for
multilib, stable use masking, python-exec, and whatever other issues
are lurking beneath the surface.

Rich

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Wed, 13 Nov 2013 14:25:11 +0100
Thomas Kahle <tomka@gentoo.org> wrote:

> Hi,
> 
> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
> > On Wed, 13 Nov 2013 10:28:02 +0000 (UTC)
> > Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> > 
> >> Hello.
> >>
> >> The new "features" use.stable.mask and package.use.stable.mask
> >> have turned maintaining systems with mixed ARCH and ~ARCH keywords
> >> into a nightmare:
> > 
> > They are considered unsupported by many; so, going down that path
> > you need to be acquainted with Portage enough to keep a consistent
> > system.
> 
> This argument has come up several times, but is it valid?

For more insight see

http://comments.gmane.org/gmane.linux.gentoo.devel/87839

and I quote "quite a few bugs are closed as invalid when a mixed system
is detected" as well as "mixing stable and testing is (likely) invalid
when unmasking one package in the unstable branch causes (reverse)
dependency resolution issues with another package in the stable branch".

Not to forget that we often test with everything stable or with
everything on testing; so, if you mix packages from both you end up in
untested situations where dependencies do not match what we intend.
Some of us fix them, but not everyone might; others might even just end
up setting a dependency range because of the stable / unstable mix.

Besides it being unsupported by some (I'll drop the "many" sound to it)
there are also just users in general that suggest others to avoid it;
simply because of the blockers and conflicts it brings along, it's
something that works out well for users that deeply understand what is
going on but for new users it is just a recipe for disaster.

Regardless of that, in my opinion, we should avoid encouraging
situations that result in having to deal with more unnecessary blockers
and conflicts; but that doesn't mean we don't want to see it. The same
link above highlights how it can help rather than obstruct Gentoo too.

> For me
> and other people I know, the main reason to use Gentoo is the
> rolling release model and this implies that you can mix package
> versions as long as version dependencies are satisfied. When the
> dependency is "cat/package" then this should mean that it works
> with every version.  If it does not, then the ebuild's
> dependencies should be updated.

Given that maintainers often test against test versions and that arch
teams often test against stable versions, nobody really tests the rests
of the situations except for some people that mix and come across it;
so, effectively the version dependencies do not always match reality
and therefore cannot imply that you can mix it.

It's also very unrealistic to check every package for every bump; at
least not with the amount of work compared to the amount of manpower we
have, it does happen a lot and we are required to do so to some extent.
But you will note that this ends up in situations where the new version
just ends up being in package.mask for a long while, for example ffmpeg.

Others are either new and forgot or might show a lack of care; which
results in it being properly tested for non-mixed systems, but not
properly tested for mixed systems. Enumerating all dependency versions
is a quite busy job; we often rely on the restrictions listed
in ./configure.{in,ac} but those are not always correct either,
sometimes they are even just absent.

> The handbook says nothing about "unsupported":
> 
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=3
> 
> If "many" choose to change this policy, there is no reason
> anymore for me to use Gentoo.

Which policy? It does not say anything about "supported" either. I
believe that its intention has always been to change it for some
packages, not for wide sets of them; the former doesn't cause much
problems, the latter is a recipe for disaster...

Note that it is merely unsupported by some developers, there are
definitely other developers that support it; and this does not imply
anything at all about our support venues.

> >> Similarly to the (fortunately dropped) concept of forcing
> >> useflags if certain packages are installed this forces a
> >> magic on the user which can hardly be managed since it is
> >> not clearly presented to the user but hidden in some profiles.
> >>
> >> As I understand, it tries to solve a "social" issue
> >> (that an ARCH user might set a USE-flag which eventually
> >> pulls in an ~ARCH package) on a technical level
> >> (by forcibly disabling the USE-flag for the user).
> > 
> > That's one approach, it might also be used when a package can be
> > stabilized but a certain of feature of the package cannot; eg.
> > USE="minimal" could be broken on a certain package because it
> > removed a bit too much, thus it could be stabilized with
> > USE="-minimal" forced.
> > 
> > Anyhow, I think we should make sure to weight "why we need to have
> > it" against "how it bothers which users"; and not just focus on
> > users alone.
> > 
> > And other than that, are there alternatives? Something we can do
> > better?
> 
> We could consider reducing the feature set of portage and live
> with the "problems" that arise.  When I started using Gentoo a
> package could simply not go stable until all dependencies for all
> USE flags were also stable.  Masking USE flags was reserved to a
> short list of very special architecture depend special cases.
>
> [...]

Doesn't that block stabilization too aggressively?
 
> >> 2. Just a few days ago dev-lang/python-exec:2 became stable
> >> on amd64, but dev-python/python-exec:2 is still ~amd64.
> >> Just to be sure to not miss anything, I have put the latter
> >> into package.accept_keywords, and hell break loose:
> > 
> > Hell indeed breaks loose if you mix stable and unstable; but note
> > that this package had an accident, see the related news item for
> > details.
> 
> Do you mean stable and unstable in this case, or in general?
> 
> [...]

General; but well, depends on how you mix things. A few packages won't
hurt, any larger than that and blockers and conflicts are all around
your ears...

> In general I share the sentiment.  The complexity of using
> portage has increased a lot lately.  Not only does it take long
> to find out why things suddenly go wrong after tree sync, also
> just the time until 'emerge -avUDN world' comes back with a
> proposal has grown to several minutes where it was few seconds
> when I started with Gentoo.

Yes, while I'm not completely sure as it gradually changed; I have the
feeling it was much shorter back in the days. Though it could be a bit
of a bias because the amount of packages I use has grown since as well.

> There has been a lot of effort to make revdep-rebuild unessecary,
> but now that it is mostly implemented, I don't know if it was
> worth the price.

emerge-time_current = emerge-time_previous + revdep-rebuild-time

is how it feels like for me; just a move of time, but I feel like it's
not the right one. Anyhow, there are parameters to disable the
subslots; just as well you can disable preserved-rebuild.

Maybe it does make more sense to run a longer process once after all
emerges, than opposed to have it run again on every single emerge.

> I spend more time now just reconfiguring
> keywords to update the system than I spent back in the old days
> where revdep would just fix things.

Not sure what the relation between keywords and revdep-rebuild is.

> If the answer is, that I
> should not mix arch and ~arch, then I'll not use Gentoo anymore.

We suggest you not to; there are enough people around to give support
for it regardless, I'm yet to come across a problem that can't be fixed.

Please don't take my words for final and consider other people's
opinion on this thread as well; I don't know the numbers, so it is hard
to tell what the general opinion on this is. Parts of this post are
therefore personal opinion or a personal view not necessarily matching
by opinion, other parts are quoted and/or might match the truth.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Wed, 13 Nov 2013 08:37:51 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> That said, your original email contained a few separate issues and
> they're probably best dealt with individually.

Just to set things straight: Note that these were different authors.

> We're not going to have a common solution for multilib, stable use
> masking, python-exec, and whatever other issues are lurking beneath
> the surface.

Not *yet*... :D

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Tom Wijsman <TomWij@gentoo.org> wrote:
>> The new "features" use.stable.mask and package.use.stable.mask
>> have turned maintaining systems with mixed ARCH and ~ARCH keywords
>> into a nightmare:
>
> They are considered unsupported by many

We can make a vote, but I would be very surprised if there are
many stable users without any unstable package.

>> As I understand, it tries to solve a "social" issue
>> (that an ARCH user might set a USE-flag which eventually
>> pulls in an ~ARCH package) on a technical level
>> (by forcibly disabling the USE-flag for the user).
>
> That's one approach, it might also be used when a package can be
> stabilized but a certain of feature of the package cannot; eg.
> USE=3D"minimal" could be broken on a certain package because it removed a
> bit too much, thus it could be stabilized with USE=3D"-minimal" forced.

As I said, it is a technical means to solve a social issue:
Instead of communicating to the users that Gentoo does not consider
USE=minimal stable, one *forces* USE=-minimal behind their back, even
if they should have decided to select it explicitly.

> Sometimes problems can be resolved by better communication too; perhaps
> there are things we can inform the user about in pkg_postinst

This would be the reasonable case for the USE=minimal example
(maybe even already in pkg_setup). There are also other ways to
communicate this to the user; I_KNOW_WHAT_I_AM_DOING names etc.
is another one.

> improve Portage to let the user know of a particular forced USE flag.

If you just remove use.stable.mask, portage will tell exactly
this to the user: That some package needs to be unmasked for
a certain dependency to be satisfied.
Then it is up to the user to decide whether he wants unmasking
or setting the use-flag. Instead making the choice behind his
back (against the use-flag) is bad IMHO.

> That are indeed the two approaches, I don't see a problem with putting
> the version itself in accept_keywords or overriding the profile;

Putting a stable version into accept_keywords will (correctly) be
considered redundant by all tools which cleanup your accept_keyword:
It makes no sense, and using it only to work around the issues
which use.stable.mask introduced appears plainly false.

Overriding in the profile of e.g. use.stable.mask cannot be done
for a single package; you can only negate a whole entry. In fact,
if you want something here, you are more or less almost forced
to negate all entries of {package.,}use.stable.mask
This is why I ask whether the latter must be there in the first place.

In fact, checking what actually is there, you find:

1. Hundreds of packages with abi_x86_32
2. python_{single,}targets_*
3. 5-10 packages with USE-flags like "unstable" or "clang" for which
   it should be clear for any stable user that he does not want to
   activate it without knowing what he is doing resp. caring about
   the dependencies.
4. Nothing else.

So practically only stuff which already caused grief plus very few
normal stuff which better should be communicated if it is not
obvious anyway.

>> The really bad thing is that this is happening by magic
>> "behind the user's back"
>
> System upgrades have to be done carefully; so, the user skipping it is
> something we cannot account for

So just to get it right:
There was something introduced to avoid communication which does
something behind the user's back which in many cases can be just
the opposite that the user wanted. You expect the user to check
the output carefully so that he can recognize that somebody is
trying to trick him, and if he analyzes the profiles he can
eventually find out what it is.
Do you really consider this better than reporting to the user
that some testing package is pulled in by a USE-flag he had set?
(Which would be the effect without use.stable.mask)

>> Since there are many reasons why use-flags can appear in ()
>> he will probably not even conjecture that actually something
>> will not be working as he expected.
>
> Most of these reasons can be uniquely determined from the output

Any mask is displayed the same. But this is not the point:
stable.mask was introduced to avoid communication with the user
by trying to guess what he means (in contrast to: doing what he
writes in the config-files).
Now you expect him to read carefully output and even improve
output only that he can decide whether portage's guesses are
right or whether he has to work against his profile.

Such tools which try to be more clever than the user always
cause trouble. Please recall this mechanism which was used
previously to "guess" useflags based on installed packages
(I even forgot the name, since this was fortunately removed).
This is nothing compared to the magic which stable.mask forces,
since the latter cannot simply be overrided by configuring
package.use appropriately.

>> But suddenly portage spitted unexplainable dependency errors,
>> and I only expert users manually reading the profiles can
>> understand that the reason is that use.stable.mask requires
>> that stable versions need to be keyworded ~amd64
>> (or use.stable.mask has to be overridden in my profile).
>
> This confuses me; isn't the goal to have one multilib apprach or the
> other? Especially due to the blockers between them.

This discussion does not belong here; I decided for ABI_X86="32"
and expect portage to respect this decision and not disabling
it randomly for some packages just because I did not mark a
stable package testing.

Yes, I understand the mechanism and how to override it, but this
is all tricky and cumbersome: Essentially, you have to spend a
lot of time just to work against the stable.mask mechanism.
The intention was probably that this mechanism should be
helpful and simplify things, but it turns out that it does
just the opposite. So one should think it over and remove it
(or replace it by something better if one finds something).

>> 2. Just a few days ago dev-lang/python-exec:2 became stable
>> on amd64, but dev-python/python-exec:2 is still ~amd64.
>> Just to be sure to not miss anything, I have put the latter
>> into package.accept_keywords, and hell break loose:
>
> Hell indeed breaks loose if you mix stable and unstable

Again, one might do a vote, but I would be surprised if not
80-90% of the stable users also have unstable packages.

> but note that this package had an accident, see the related
> news item for details.

This is why it took me so long to find out; of course, I thought
that the problem is related with the news while it was actually
related with use.stable.mask

>> Portaqe wanted me to emerge the git version of
>> dev-lang/python-exec:0 and reemerge dozens of packages.
>
> This is a consequence of that hell; if you don't agree and this is due
> to the Portage tree, please show the dependency chain that causes this.

Please read, what I had written: I have explained why this happened.
It is because use.stable.mask horribly interacts with the dependency
chain: Use flags change out of nothing if you are forced to add an
unstable keyword somewhere.

>> I needed hours to find out what is the actual cause:
>> The package.accept_keywords caused the use.stable.mask of
>> python_targets_pypy2_0 und python_targets_python3_3 to become
>> ineffective for dev-python/python-exec,
>
> It doesn't matter, dev-python/python-exec installs no contents.

This is the point: You have an actual "useless" package which
due to use.stable.mask hinder dependencies from being corrrectly
resolved. And which even forces other packages to be rebuilt,
also because of changes only in use.stable.mask.

>> but of course it is still
>> effective for dev-lang/python-exec which is not be the case
>> if I unmask the git version of dev-lang/python-exec.
>
> Which one is not meant to do anyway; and from what you wrote, I don't
> think you intent to either.

Exactly, but this is the only solution which portage can
find; again, because use.stable.mask implicitly changes the
dependency chain.

>> This is completely confusing since nowhere the git-version
>> is marked differently than the non-git version.
>
> Marked in which way? One is stable, the other unkeyworded.

They provide exactly the same USE-flags, and whenever they
occur in profiles or dependencies they occur both or none.
So one has a hard time to guess why the git version satisfies
a dependency which is not satisfied by the stable version.
Of course, if one knows the answer (use.stable.mask), it is clear.
Instead of making things simpler for the user, use.stable.mask
causes problems to the user.
It causes much more problems than it solves: Actually the only
problem which it solves (or better: tries to solve) is a
communication problem...

> If it is due to the hell above, we warn users up front for that.

Most users mixing stable and unstable have valid reasons
for each case. Telling "we have told you not to do that"
only to keep a smart-ass mechanism which produces more
problems than it solves is a bad idea.

>> 3. As a side effect of 2., I realized that libreoffice and a dozen
>> further packages get forced a rebuild. So, if eventually
>> python-3.3 becomes stable and is removed from use.stable.mask, [...]
>
> That is to be expected on such stabilizations, I doubt they are
> unnecessary

Only because some package which I have not even installed changed
its stability, it should be necessary that I reemerge everything?
And even *if* I should have installed it, the change of its
stability would make it necessary to reemerge my world?
Things appear very strange in Gentoo land meanwhile...

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-13, o godz. 10:28:02
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> napisał(a):

> As I understand, it tries to solve a "social" issue
> (that an ARCH user might set a USE-flag which eventually
> pulls in an ~ARCH package) on a technical level
> (by forcibly disabling the USE-flag for the user).
> Solving social problems by technical means is never a good
> idea:

Then you don't understand it.

The basic issue is that we couldn't stabilize a package without
stabilizing all of its optional dependencies. For example, consider
Python 3.3. In order to get proper testing of it on testing, we had to
enable support for it in packages. But when we introduced that support,
the package immediately gained a dep on python:3.3.

If the package was supposed to go stable, we would either have to
stabilize Python 3.3 (too early for that), wait for Python 3.3
(resulting in very long to infinite) or drop Python 3.3 support. There
were even cases when I had to revbump a package in order to keep
'limited' revision to stabilize and 'full' to keep testing.

Just to be clear -- this isn't only a social issue. This is a valid QA
concern that we had no distinction between 'flags that are fine on
stable' and 'flags that are not'. If some flags work and some do not,
resulting in 'unsatisfiable dep' errors, this is technical.

> While the former gives the stable user a clear message
> what is going wrong (after all, many stable users want
> some package which has not a stable version yet, so this
> should be something everybody should be able to handle),
> the latter hides causes and makes things almost unpredictable:

Answer yourself the following questions: does portage suggest removing
the flag in the case? Does portage in any way explain that a particular
dependency was pulled in due to USE flag?

It's easy to use words like 'clear message' when you want to prove your
point. And I have no idea what you mean by 'something everybody should
be able to handle', unless you assume that the main purpose of a stable
system is to turn it into mixed-keyword system.

And just in case: the proper course of action then is to *report
a bug*. And in the end, thanks to your glorified solution, we end up
with dozens or hundreds of 'CANTFIX' bugs.

> Even if the user has put the dependency into
> package.accept_keywords, he will not be able to use the
> USE-flag on his packages unless
> *he puts stable versions into package.accept_keywords*
> (or - simlarly worse - overrides the profile).

If you have a problem with USE flag being masked, you unmask the USE
flag. It is simple like this.

I don't agree with the whole idea of unmasking flags via playing with
accept_keywords. In my opinion, it's just a terrible bug or mis-design.
It's not something that should be encouraged, or even happen.

If you unmask testing package just to get testing keywords, you quickly
lose the point of having stable keywords. Putting just the stable
versions is a pointless nightmare.

Even worse than that, people with mixed systems get extra flags even if
they don't want them. And this is an easy way to have them end up with
half of the system on testing.

> The really bad thing is that this is happening by magic
> "behind the user's back", i.e. contradicting the user's setting
> of USE-flag and package.use: If the user does not carefully
> read emerge's -v output, he even does not get informed that
> the support for his unstable package is dropped from the
> stable package, despite he might have specified the corresponding
> USE-flag globally. Even worse, even when reading the output
> carefully, the user cannot understand the reason:
> Since there are many reasons why use-flags can appear in ()
> he will probably not even conjecture that actually something
> will not be working as he expected.

It's magic only because you did it wrong.

> Here are some other examples of negative effects happening
> just recently to me, ordered from not so severe to very bad:
> 
> 1. For several reasons I always want the most current
> emul-linux-x86* libraries, so they are in package.accept_keywords.
> Due to global ABI_X86=32 (which I also want), this forced me
> of course to put several libraries to ~amd64 since only
> new version support this. Some of the libraries are actually
> stable, so I have removed them from package.accept_keywords.
> So far, so good.
> But suddenly portage spitted unexplainable dependency errors,
> and I only expert users manually reading the profiles can
> understand that the reason is that use.stable.mask requires
> that stable versions need to be keyworded ~amd64
> (or use.stable.mask has to be overridden in my profile).

Which wouldn't happen if package.accept_keywords didn't implicitly
unmask flags.

> 2. Just a few days ago dev-lang/python-exec:2 became stable
> on amd64, but dev-python/python-exec:2 is still ~amd64.

And this was a bug that would have been fixed if you cared reporting it
straight to us rather than kept is as an argument.

> 3. As a side effect of 2., I realized that libreoffice and a dozen
> further packages get forced a rebuild. So, if eventually
> python-3.3 becomes stable and is removed from use.stable.mask,
> all stable users will have to rebuild almost their whole world,
> because python-exec then has one more "dummy" USE-flag. The same
> will happen again if pypy-2.0 becomes stable.
> So a lot of unnecessary rebuilds happen to stable users because
> of {package.,}use.stable.mask which most of the developers
> (who are often ~amd64 users) do not realize.

I don't get this. A masked flag is equivalent to a disabled flag. What
would cause the rebuild then?

-- 
Best regards,
Michał Górny

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

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Duncan]

Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as excerpted:

> On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle <tomka@gentoo.org> wrote:
>> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
>>> On Wed, 13 Nov 2013 10:28:02 +0000 (UTC)
>>> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
>>>
>>>> Hello.
>>>>
>>>> The new "features" use.stable.mask and package.use.stable.mask have
>>>> turned maintaining systems with mixed ARCH and ~ARCH keywords into a
>>>> nightmare:
>>>
>>> They are considered unsupported by many; so, going down that path you
>>> need to be acquainted with Portage enough to keep a consistent system.
>>
>> This argument has come up several times, but is it valid?
> 
> Honestly, opinions vary on this one and I don't think it is a productive
> path to go down.  I also feel that being able to mix keywords is a big
> benefit of using Gentoo.  I'd rather focus on practical ways to make
> this easier rather than whether it is desirable.
> 
> That said, there are always going to be situations where mixing keywords
> isn't practical.  You're not going to run stable chromium against ~arch
> v8, or mixed keywords between kdelibs and kwin, etc.

FWIW, I believe at least part of the confusion here is based on differing 
definitions of "supported".

Mixing ~arch/arch keywords is "supported" in that gentoo makes it 
possible, and in the generic case, relatively easy.

It's "unsupported" in that it's a not generally tested case:

[TL;DR folks can skip this whole post from here.  It's mostly 
philosophical rambling attempting to backup the above claim.]

The all-~arch tree case is basic sanity tested by devs when the introduce 
the package with ~arch keywords, and further by the many users (including 
me) who run all ~arch systems and wouldn't have it any other way.  So 
while there's a measure of risk in it, chances are others on ~arch are 
running into any problems at about the same time, and bugs will be 
reported and generally either fixed or a workaround (patch in a bug if 
not yet in tree, or a bug comment saying it works use flag X turned off, 
etc) will be available, within a relatively short period.

The all arch-stable tree is tested as well, by the various arch devs and 
arch-testers before they stabilize a particular package with tests 
against an otherwise fully stable tree, and further by the various users 
running that.

A mixed stable/~arch installation, however, is an undefined and mostly 
untested case, and by domain definition will remain so, simply because of 
the combinational explosion in the number of possible variants.

(Note that an argument of "simpler" and mostly binary distros is that 
gentoo is /already/ that way, due to the combinational explosion of all 
the various USE flag possibilities -- already that's beyond testing every 
combination possible, but gentooers learn to live with and accept that 
level of risk and the possibility that they may have to change a USE flag 
to get something to work because that combination wasn't tested and 
breaks, from time to time.  But the combinational possibilities are at 
least within reason there, all the combinational possibilities of stable 
with unstable is and will remain unsupportable in practice if not in 
name, at least if "supportable" is defined with any strictness at all.)

Thus, by defintion of the mixed stable/~arch domain, it's simply 
impossible to test and thus to support in any sort of "this unstable 
package tested and demonstrated to work with a random mix of stable/~arch 
packages" way, at all!

So in that regard, a mixed stable/~arch system is and will remain 
unsupported, simply because it's impossible /to/ support.

That notwithstanding, gentoo DOES make it possible, even "easy" (note the 
scare-quotes), to run a mixed stable/~arch system.  And the /ability/ to 
do so remains supported.  However, users should know that in doing so 
they're running a combination that isn't commonly tested, indeed, that 
CANNOT be fully tested (even more so than the USE flag thing in general 
means for gentoo), and should understand and be willing to accept the 
added risk and manual sysadmin care necessary as a result.

And part of accepting that means that yes, they might have some bugs 
closed with, effectively, "if it hurts when you bang your head against 
the wall, quit banging your head against the wall", INVALID, NOTABUG, 
etc, along with the associated recommendation to stick with either fully 
~arch or fully arch, at least for that package and its dependencies.

And similarly, there WILL be more headaches with stuff like 
package.stable.use overrides, etc, because by domain definition, that 
sort of additional manual maintenance burden and responsibility comes 
with the mixed stable/~arch domain.

But whether that's considered "unsupported" or not depends on how strict 
and individual's definition of "supported" actually is.  THIS is where 
opinions differ, at least in my /own/ opinion, as explained above.

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

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Tom Wijsman <TomWij@gentoo.org> wrote:
>
> and I quote "quite a few bugs are closed as invalid when a mixed system
> is detected"

I think nobody is speaking against this possibility:
If it causes too much grief to the maintainer to list all blockers
explicitly, I think everybody can agree if he says that if it breaks
you keep the pieces.

However, it is a different thing to treat mixing generally like ricing
and to introduce mechanisms which - as my example hopefully show -
can be *expected* to break usability of a mixed systems:

There are valid reasons to not have a testing system (besides the
obvious desire for stability another one is too frequent updates),
but there are also many valid reasons why you need some package(s)
which pull in a lot of unstable dependencies.

I think the "typical" use case even is a mixed system, since
most systems will require some special applications (related to
the main task this system is supposed to do; perhaps development
of something which needs a lot of unstable packages) while
on the other hand this does not mean that *everything* in the
system should be testing and frequently updated.

BTW, another reason for mixing which was not mentioned yet is
users of multiple architectures (e.g. amd64 and x86) wanting to
have the same versions installed (e.g. to use the same tarballs);
although, as a rule, amd64 and x86 do not differ *much*, they usually
always differ in a few packages since some team always stabilizes first.

> Given that maintainers often test against test versions and that arch
> teams often test against stable versions, nobody really tests the rests
> of the situations [...]
>
> It's also very unrealistic to check every package for every bump

Again, I think nobody expects that there never will be any trouble
on a mixing system.  But it is one thing whether this trouble occurs
from time to time - when things are running badly - or whether the
package manager uses a mechanism which can be expected to break on
mixing system.

> Which policy? It does not say anything about "supported" either. I
> believe that its intention has always been to change it for some
> packages, not for wide sets of them; the former doesn't cause much
> problems, the latter is a recipe for disaster...

With use.stable.mask you get problems even with one
unstable package unless you verify manually that no
useflag related to this package is in use.stable.mask
And if it is, you are lost in the sense that you have to
eliminate the provided use.stable.mask.
So what has use.stable.mask achieved? It has forced to you
to eliminate the mechanism and nothing else.

>> We could consider reducing the feature set of portage and live
>> with the "problems" that arise.  When I started using Gentoo a
>> package could simply not go stable until all dependencies for all
>> USE flags were also stable.  Masking USE flags was reserved to a
>> short list of very special architecture depend special cases.
>>
>> [...]
>
> Doesn't that block stabilization too aggressively?

Maybe, maybe not. It is exactly this social/political question which
is attempted to be solved by technical means with use.stable.mask.
This is what does not work:
You cannot solve this question (whether to relax this policy;
are there any exceptions valid and if yes which one) by a technical
tool which forces a certain other decision onto the user.
It is just shifting the problem and causes additional headache.

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Thomas Kahle]

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

On 11/13/2013 03:30 PM, Duncan wrote:
> Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as excerpted:
> 
>> On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle <tomka@gentoo.org> wrote:
>>> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
>>>> On Wed, 13 Nov 2013 10:28:02 +0000 (UTC)
>>>> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> The new "features" use.stable.mask and package.use.stable.mask have
>>>>> turned maintaining systems with mixed ARCH and ~ARCH keywords into a
>>>>> nightmare:
>>>>
>>>> They are considered unsupported by many; so, going down that path you
>>>> need to be acquainted with Portage enough to keep a consistent system.
>>>
>>> This argument has come up several times, but is it valid?
>>
>> Honestly, opinions vary on this one and I don't think it is a productive
>> path to go down.  I also feel that being able to mix keywords is a big
>> benefit of using Gentoo.  I'd rather focus on practical ways to make
>> this easier rather than whether it is desirable.
>>
>> That said, there are always going to be situations where mixing keywords
>> isn't practical.  You're not going to run stable chromium against ~arch
>> v8, or mixed keywords between kdelibs and kwin, etc.
> 
> FWIW, I believe at least part of the confusion here is based on differing 
> definitions of "supported".

I agree.  Generally however, we should think Gentoo (or the open
source ecosystem) more bazaar, less cathedral.  Libraries have
interfaces, and they are supposed to be mixed and matched
according to the interface definitions.  We (Gentoo) should not
think of "Gentoo stable" as a fixed product like "iOS-7".  It has
come a long way, but philosophically I still think of Gentoo as a
kind of automated Linux-from-scratch (where you also mix and
match whatever you find on the Internets).

In the end it boils down to what we mean by "supported".  For me
"supported" does not mean "tested".  As you point out, testing
every combination forbids itself.  Supported for me means that
the argument "you mixed stable and unstable" is not per se valid.
There's a huge difference between

You mixed unstable firefox with stable gcc

and

You mixed unstable X server with stable protocols.

For me mixing the trees is supported in the sense that I would
apply rational judgement to bugs.  If they are of the second
type, it can be said in a polite way that we as Gentoo can't do
anything about this combination not working.

Cheers,
Thomas

-- 
Thomas Kahle


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/11/13 09:10 AM, Michał Górny wrote:
>> 
>> 1. For several reasons I always want the most current 
>> emul-linux-x86* libraries, so they are in
>> package.accept_keywords. Due to global ABI_X86=32 (which I also
>> want), this forced me of course to put several libraries to
>> ~amd64 since only new version support this. Some of the libraries
>> are actually stable, so I have removed them from
>> package.accept_keywords. So far, so good. But suddenly portage
>> spitted unexplainable dependency errors, and I only expert users
>> manually reading the profiles can understand that the reason is
>> that use.stable.mask requires that stable versions need to be
>> keyworded ~amd64 (or use.stable.mask has to be overridden in my
>> profile).
> 
> Which wouldn't happen if package.accept_keywords didn't implicitly 
> unmask flags.
> 

(I haven't read this whole thread yet, but in case it hasn't been
mentioned:)

It's also worth pointing out that the whole reason why abi_x86_32 is
{package.,}use.stable.masked is because trying to manage the partial
transisition between emul-* and multilib-build dependencies on stable
or mixed-keyworded systems is a horrible headache at the moment, due
to those exact same unexplainable dependency errors.  Without
{package.,}use.stable.mask, all stable users would have to deal with
this *right now* on their systems.


Note also that setting ABI_X86=32 globally isn't how it's supposed to
be used; the point of this flag is for dependency resolution when a
particular package requires it (ie, top-level package depends on
app-cat/dep[abi_x86_32], portage --autounmask-write sets the necessary
changes to /etc/portage/package.use).  But that's neither here nor there.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKDlI4ACgkQ2ugaI38ACPBopwD8CLqHS45H50Dg4Jnz5/JgpcKP
9BkjdulcBTGSIxyJX8sA/j2d+fojR0hCAJvsPsD24h90CWBvfhxnK824//aejoQi
=2vLL
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/11/13 09:55 AM, Thomas Kahle wrote:
> On 11/13/2013 03:30 PM, Duncan wrote:
>> Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as
>> excerpted:
>> 
>>> On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle
>>> <tomka@gentoo.org> wrote:
>>>> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
>>>>> On Wed, 13 Nov 2013 10:28:02 +0000 (UTC) Martin Vaeth
>>>>> <vaeth@mathematik.uni-wuerzburg.de> wrote:
>>>>> 
>>>>>> Hello.
>>>>>> 
>>>>>> The new "features" use.stable.mask and
>>>>>> package.use.stable.mask have turned maintaining systems
>>>>>> with mixed ARCH and ~ARCH keywords into a nightmare:
>>>>> 
>>>>> They are considered unsupported by many; so, going down
>>>>> that path you need to be acquainted with Portage enough to
>>>>> keep a consistent system.
>>>> 
>>>> This argument has come up several times, but is it valid?
>>> 
>>> Honestly, opinions vary on this one and I don't think it is a
>>> productive path to go down.  I also feel that being able to mix
>>> keywords is a big benefit of using Gentoo.  I'd rather focus on
>>> practical ways to make this easier rather than whether it is
>>> desirable.
>>> 
>>> That said, there are always going to be situations where mixing
>>> keywords isn't practical.  You're not going to run stable
>>> chromium against ~arch v8, or mixed keywords between kdelibs
>>> and kwin, etc.
>> 
>> FWIW, I believe at least part of the confusion here is based on
>> differing definitions of "supported".
> 
> I agree.  Generally however, we should think Gentoo (or the open 
> source ecosystem) more bazaar, less cathedral.  Libraries have 
> interfaces, and they are supposed to be mixed and matched according
> to the interface definitions.  We (Gentoo) should not think of
> "Gentoo stable" as a fixed product like "iOS-7".  It has come a
> long way, but philosophically I still think of Gentoo as a kind of
> automated Linux-from-scratch (where you also mix and match whatever
> you find on the Internets).
> 
> In the end it boils down to what we mean by "supported".  For me 
> "supported" does not mean "tested".  As you point out, testing 
> every combination forbids itself.  Supported for me means that the
> argument "you mixed stable and unstable" is not per se valid. 
> There's a huge difference between
> 
> You mixed unstable firefox with stable gcc
> 
> and
> 
> You mixed unstable X server with stable protocols.
> 
> For me mixing the trees is supported in the sense that I would 
> apply rational judgement to bugs.  If they are of the second type,
> it can be said in a polite way that we as Gentoo can't do anything
> about this combination not working.


The term "supported" is a rather overloaded term which tends to mean
different things in gentoo depending on the context that it is used
(and who's using it), for sure.  It's also not analogous to "working"
or "expected to work", at all, imo.

I wonder if it might be a good idea to have a discussion and reach
consensus on what the Gentoo (Developer) definition of "Supported"
should actually be, and document this somewhere so that ambiguity can
be officially removed.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKDl9EACgkQ2ugaI38ACPABTgEApL3YpwDO1aN6SrJ08byJi7L4
q5I1zYPImbooAUkm3OAA/2gGn2m1ulw6UzoQNLEtVkEzXr83iwMUvHX4jaGhUUEo
=b+5F
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Michał Górny <mgorny@gentoo.org> wrote:
>
>> As I understand, it tries to solve a "social" issue
>> (that an ARCH user might set a USE-flag which eventually
>> pulls in an ~ARCH package) on a technical level
>> (by forcibly disabling the USE-flag for the user).
>> Solving social problems by technical means is never a good
>> idea:
>
> Then you don't understand it.
>
> The basic issue is that we couldn't stabilize a package without
> stabilizing all of its optional dependencies.

Exactly: The social issue is that you have this rule fixed
without any exceptions and do not want to discuss about exceptions.

> There were even cases when I had to revbump a package in order to keep
> 'limited' revision to stabilize and 'full' to keep testing.

The social issue has to be solved and it has to be clarified
when packages are allowed to have USE-flags depending on unstable
packages which the user has to resolve when he wants them.

> Just to be clear -- this isn't only a social issue. This is a valid QA
> concern that we had no distinction between 'flags that are fine on
> stable' and 'flags that are not'. If some flags work and some do not,
> resulting in 'unsatisfiable dep' errors, this is technical.

No. The user has to be told that he *should* not use such certain
flags on a stable system. This can happen by portage reporting
a message that some USE-dependency is pulling in an unstable package,
but it can also happen in a different way.
The use.stable.mask "solution" is to not inform the user but just
decide behind his back that he cannot use the flag and enforce
this decision.
Instead, e.g. one can let portage report if some useflag described
in use.stable.mask needs to be disabled, or one can use some
"I_KNOW_WHAT_I_AM_DOING" name, or whatever. There are many ways
of reporting. But forcing a decision on the user without even
communicating reasonably why this decision was forced is very bad IMHO.

> Answer yourself the following questions: does portage suggest removing
> the flag in the case? Does portage in any way explain that a particular
> dependency was pulled in due to USE flag?

The output can easily be improved: It is not rocket
science to list "required by category/package[FLAG]" instead of
"required by category/package" or to display the relevant part
of the dependency string (something similar is done already for
REQUIRED_USE, so the logic probably already exists in portage).

> And just in case: the proper course of action then is to *report
> a bug*. And in the end, thanks to your glorified solution, we end up
> with dozens or hundreds of 'CANTFIX' bugs.

Yeah, it is much better to throw the users into dependency hell
in which they have no clue how to find out. Certainly they will
never report any bugs in this case when they can so easily solve
this by just going through all dependencies and all profiles
manually and understanding all details.

> If you have a problem with USE flag being masked, you unmask the USE
> flag. It is simple like this.

Yes, the sane way to deal with use.stable.mask for the user is to
undo manually everything which is set there.
But is it really a good feature, if the user essentially only
removes it?

> I don't agree with the whole idea of unmasking flags via playing with
> accept_keywords. In my opinion, it's just a terrible bug or mis-design.
> It's not something that should be encouraged, or even happen.

I completely agree.
But the only way to unmask it otherwise is to undo use.stable.mask.
Then why have use.stable.mask in the first place?
Moreover, for use.stable.mask this cannot happen on a per-package basis.

Perhaps one can introduce a better way to unmask use.stable.mask?

> Even worse than that, people with mixed systems get extra flags even if
> they don't want them. And this is an easy way to have them end up with
> half of the system on testing.

Do you mean by "extra flags" again those of use.package.mask?
Then isn't this again an argument against use.package.mask at all?

> It's magic only because you did it wrong.

No, it is magic because it makes a decision (pulling in ~amd64
or unsetting USE) without communicating appropriately with the user
and even without giving him a clean possibility to decide differently.
(Modifying the profile is more a hack than a clean possibility).

Moreover, once the thing is removed from use.stable.mask he gets
tricked a second time by suddenly a useflag popping up.
(OK, this time, he *does* get informed and has a clean possibility
to change, so this time his surprise is limited).

> Which wouldn't happen if package.accept_keywords didn't implicitly
> unmask flags.

Exactly. This is why it becomes a dependency hell.
But wouldn't removing this go against the purpose of use.stable.mask?

> I don't get this. A masked flag is equivalent to a disabled flag. What
> would cause the rebuild then?

All python versions are use.force'd in this package.
However, those which are use.stable.mask'ed are not use.force'd,
because use.stable.mask overrides use.force (which makes sense).
So if the use.stable.mask entry changes, the active USE-flags
in the package change automatically, and the user cannot do anything
against it (except modifying the profile).

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Mike Gilbert]

On Wed, Nov 13, 2013 at 10:23 AM, Martin Vaeth
<vaeth@mathematik.uni-wuerzburg.de> wrote:
> Michał Górny <mgorny@gentoo.org> wrote:
>>
>>> As I understand, it tries to solve a "social" issue
>>> (that an ARCH user might set a USE-flag which eventually
>>> pulls in an ~ARCH package) on a technical level
>>> (by forcibly disabling the USE-flag for the user).
>>> Solving social problems by technical means is never a good
>>> idea:
>>
>> Then you don't understand it.
>>
>> The basic issue is that we couldn't stabilize a package without
>> stabilizing all of its optional dependencies.
>
> Exactly: The social issue is that you have this rule fixed
> without any exceptions and do not want to discuss about exceptions.
>
>> There were even cases when I had to revbump a package in order to keep
>> 'limited' revision to stabilize and 'full' to keep testing.
>
> The social issue has to be solved and it has to be clarified
> when packages are allowed to have USE-flags depending on unstable
> packages which the user has to resolve when he wants them.
>
>> Just to be clear -- this isn't only a social issue. This is a valid QA
>> concern that we had no distinction between 'flags that are fine on
>> stable' and 'flags that are not'. If some flags work and some do not,
>> resulting in 'unsatisfiable dep' errors, this is technical.
>
> No. The user has to be told that he *should* not use such certain
> flags on a stable system. This can happen by portage reporting
> a message that some USE-dependency is pulling in an unstable package,
> but it can also happen in a different way.
> The use.stable.mask "solution" is to not inform the user but just
> decide behind his back that he cannot use the flag and enforce
> this decision.
> Instead, e.g. one can let portage report if some useflag described
> in use.stable.mask needs to be disabled, or one can use some
> "I_KNOW_WHAT_I_AM_DOING" name, or whatever. There are many ways
> of reporting. But forcing a decision on the user without even
> communicating reasonably why this decision was forced is very bad IMHO.

Let's talk about the development workflow we use for a minute:

Say I want to stabilize a package on a given architecture. One of the
first tests I run is to change KEYWORDS and run repoman. repoman will
check to ensure that all dependencies are at least visible with the
given set of KEYWORDS. This is a fairly important check, and it often
prevents major fuck ups.

If we were to remove use.stable.mask, I as a developer would require
some alternate way to declare a use flag unsupported on stable so that
repoman knows not to check the optional dependencies for it with
stable keywords.

This is not a completely social issue; there is a very real
technical/QA issue that needs to be addressed on the development side.
If you can figure that out, we can talk about changing the end-user
experience.

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Kent Fredric]

On 14 November 2013 04:23, Martin Vaeth
<vaeth@mathematik.uni-wuerzburg.de> wrote:
> The use.stable.mask "solution" is to not inform the user but just
> decide behind his back that he cannot use the flag and enforce
> this decision.
> Instead, e.g. one can let portage report if some useflag described
> in use.stable.mask needs to be disabled, or one can use some
> "I_KNOW_WHAT_I_AM_DOING" name, or whatever. There are many ways
> of reporting. But forcing a decision on the user without even
> communicating reasonably why this decision was forced is very bad IMHO.


Ah, that explains why I hadn't thought I'd seen what this subject was
about, because I expected when I saw

   (-foo)

In emerge's overview output, that the flag "foo" was simply
hard-masked profile-wide, for "some reason".

If there was better indication that these flags are simply masked due
to a stability level difference, I'd have expected a different
indicator in the output.

Seems as this is the reality we have:

ebuild:  stable, unstable, hardmasked/experimental
useflag: stable, hardmasked/experimental

Seems logical we make useflags potentially be:

useflag: stable, unstable, hardmasked/experimental

"Somehow", or at least, if that is already the case, it needs to be
more obvious what is occurring, and what steps we should be taking if
we want to work around it.

Maybe IUSE can be extended in a future EAPI to have ~ , or we could
have a seperate variable to indicate useflag stability.

ideas:
   -foo   #  I don't want foo, but defer if stability differences make
that impossible.
  -~foo   #  I don't want foo, and I don't care if removing foo
reduces stability.
  -**foo # I don't care if foo is experimental , turn that shit off

or something.

At very least, emerge --pretend  should say something like

   ((~)-foo)

To indicate foo is turned off due to a stability mask, though I don't
know how to make it clear to end users what that means. Just showing
something different however is often enough to make interested parties
curious.

-- 
Kent

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-13, o godz. 15:23:44
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> napisał(a):

> Michał Górny <mgorny@gentoo.org> wrote:
> >
> >> As I understand, it tries to solve a "social" issue
> >> (that an ARCH user might set a USE-flag which eventually
> >> pulls in an ~ARCH package) on a technical level
> >> (by forcibly disabling the USE-flag for the user).
> >> Solving social problems by technical means is never a good
> >> idea:
> >
> > Then you don't understand it.
> >
> > The basic issue is that we couldn't stabilize a package without
> > stabilizing all of its optional dependencies.
> 
> Exactly: The social issue is that you have this rule fixed
> without any exceptions and do not want to discuss about exceptions.

Did you ever do any serious package work, or are just discussing
theory?

Repoman is not a social tool. It's a technical dep checker, and if you
start allowing exceptions to the rules, its output will *soon* become
useless since you would have to filter out all the allowed exceptions
and hope they didn't hide a valid issue.

> > Just to be clear -- this isn't only a social issue. This is a valid QA
> > concern that we had no distinction between 'flags that are fine on
> > stable' and 'flags that are not'. If some flags work and some do not,
> > resulting in 'unsatisfiable dep' errors, this is technical.
> 
> No. The user has to be told that he *should* not use such certain
> flags on a stable system. This can happen by portage reporting
> a message that some USE-dependency is pulling in an unstable package,
> but it can also happen in a different way.
> The use.stable.mask "solution" is to not inform the user but just
> decide behind his back that he cannot use the flag and enforce
> this decision.

Let's move this a few blocks back. So, on a regular stable system,
should portage report you every time that this new package version is
not tested and you shouldn't be using it? But it will be just
a suggestion, you need to manually choose the older version if you want
to follow it...

Do you see now what you are proposing?

> > Answer yourself the following questions: does portage suggest removing
> > the flag in the case? Does portage in any way explain that a particular
> > dependency was pulled in due to USE flag?
> 
> The output can easily be improved: It is not rocket
> science to list "required by category/package[FLAG]" instead of
> "required by category/package" or to display the relevant part
> of the dependency string (something similar is done already for
> REQUIRED_USE, so the logic probably already exists in portage).

If it can easily be improved, then why didn't *you* improve it yet? Go
for it, then tell us how easy it was. Then we can consider what to do
next.

> > And just in case: the proper course of action then is to *report
> > a bug*. And in the end, thanks to your glorified solution, we end up
> > with dozens or hundreds of 'CANTFIX' bugs.
> 
> Yeah, it is much better to throw the users into dependency hell
> in which they have no clue how to find out. Certainly they will
> never report any bugs in this case when they can so easily solve
> this by just going through all dependencies and all profiles
> manually and understanding all details.

We must be having different users. Because as far as I know, we have
users throwing quite-a-long emerge outputs from time to time.

Of course, there are ricers too. The people who are going to mess up
their systems and suggest others to do the same, just to prove they
solve any problem in the worst way possible.

> > If you have a problem with USE flag being masked, you unmask the USE
> > flag. It is simple like this.
> 
> Yes, the sane way to deal with use.stable.mask for the user is to
> undo manually everything which is set there.
> But is it really a good feature, if the user essentially only
> removes it?

Are stable keywords a good idea if the user essentially only overrides
them with package.accept_keywords?

The point you are missing is that we actually have stable users who
essentially want *stable* system. Those people don't want to get
testing packages unless absolutely necessary, and they'd rather wait
for Python 3 to go stable than unmask the flag for the fun of it.

> > I don't agree with the whole idea of unmasking flags via playing with
> > accept_keywords. In my opinion, it's just a terrible bug or mis-design.
> > It's not something that should be encouraged, or even happen.
> 
> I completely agree.
> But the only way to unmask it otherwise is to undo use.stable.mask.
> Then why have use.stable.mask in the first place?

And by using 'package.use' you 'undo' USE defaults in packages
and global flag defaults, and... why do we have USE flags at all? We're
just all undoing stuff anyway.

> Moreover, for use.stable.mask this cannot happen on a per-package basis.

It's called package.use.stable.mask.

> Perhaps one can introduce a better way to unmask use.stable.mask?

Like what?

> > Even worse than that, people with mixed systems get extra flags even if
> > they don't want them. And this is an easy way to have them end up with
> > half of the system on testing.
> 
> Do you mean by "extra flags" again those of use.package.mask?
> Then isn't this again an argument against use.package.mask at all?

I mean stable-masked flags. So you get 2-in-1 with no clear indication
that you got an extra unmask.

> > I don't get this. A masked flag is equivalent to a disabled flag. What
> > would cause the rebuild then?
> 
> All python versions are use.force'd in this package.
> However, those which are use.stable.mask'ed are not use.force'd,
> because use.stable.mask overrides use.force (which makes sense).
> So if the use.stable.mask entry changes, the active USE-flags
> in the package change automatically, and the user cannot do anything
> against it (except modifying the profile).

Then the user gets to rebuild python-exec which is a tiny C executable.
Reverse dependencies are not rebuilt.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Wed, Nov 13, 2013 at 10:02 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> It's also worth pointing out that the whole reason why abi_x86_32 is
> {package.,}use.stable.masked is because trying to manage the partial
> transisition between emul-* and multilib-build dependencies on stable
> or mixed-keyworded systems is a horrible headache at the moment, due
> to those exact same unexplainable dependency errors.  Without
> {package.,}use.stable.mask, all stable users would have to deal with
> this *right now* on their systems.

Indeed, by mixing keywords/etc Martin is basically having to deal with
this mess *right now.*

>
>
> Note also that setting ABI_X86=32 globally isn't how it's supposed to
> be used;

I never really viewed the new multilib stuff as being "ready for
primetime" anyway.  That isn't meant to reflect on its level of
quality/etc - just that it isn't completely rolled out and the
docs/etc aren't really designed for end-user consumption yet.

Users who take advantage of new features in these kinds of states are
going to run into problems.  That's just the cost of being on the
cutting edge.

Rich

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Kent Fredric <kentfredric@gmail.com> wrote:
>
> Maybe IUSE can be extended in a future EAPI to have ~

I like this "~foo" idea very much from the user's point of view:
You see clearly why useflags are disabled, and one could have a
"simple" mechanism to override it.

However, extending IUSE is not the correct way, because
you would need a matrix in every ebuild which cannot be
reasonably maintained: Every useflag can be masked or stable on
each architecture differently. So, supporting the currently
existing {package,}.use.mask in the profiles might make sense,
just the effect needs to be modified somewhat.

1. A tiny change in the display: ~foo instead of (-foo)
2. A more severe change in the way how to unmask it:

(a) ACCEPT_KEYWORD=~ARCH can unmask it (as currenttly).

(b) /etc/portage/package.accept_keywords does *not* unmask it
    (contrary to now); this would avoid the dependency hell.
    Instead:

(c1) The entry ~foo in /etc/portage/package.use unkeywords foo.
     Alternatively (or in addition):

(c2) The entry foo in /etc/portage/package.use.accept_keywords
     unmasks it; this could be even extended with architectures
     and '**' as the current accept_keywords.

(d) Of course, changing the profile (like overriding it in
    /etc/portage/profile) can unmask it, too (as currently),
    but this should not be encouraged.

If I see it correctly, this would not even require an EAPI bump,
since /etc/portage/package.* files are not subject to pms.

I hope that (b) is not hard to implement in portage, since
it means that portage has to keep track about the cause of
an unkeywording.

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Michał Górny <mgorny@gentoo.org> wrote:
>
> Repoman is not a social tool. It's a technical dep checker, and if you
> start allowing exceptions to the rules

Repoman might still access use.stable.mask without having
portage force it on users.

The social conflict I mean is: You *want* that users do not
decide for ~ARCH but instead always against enabling the
USE-flag, so you make it technically very hard for them
to even recognize that a decision is being made for them.

The solution in the other posting with displaying ~foo
(and simple unmasking) gives the user the freedom back.

> Let's move this a few blocks back. So, on a regular stable system,
> should portage report you every time that this new package version is
> not tested and you shouldn't be using it?

I did not mean that portage should report *every* time:
I meant that portage report if a stable.masked USE-Flag is disabled.
So you make the decision to either disable the USE-Flag for this
package or to disable the stable.mask by whatever mechanism
(e.g. by package.use_accept_keywords or something similar
or by overriding the profile or something else).

However, if package.accept_keywords does no magic on package.use,
perhaps a clear indication in the output like ~foo is sufficient.
(Otherwise you might not even get to such an output due to
dependency hell).

> If it can easily be improved, then why didn't *you* improve it yet?

A lot of portage output might be improved if one is willing to
spend enough time. But this is not the topic of the discussion.
Please, do not build a strawman like ...

> Then we can consider what to do next.

... and then thinking about 9 other tasks (of course, all
must be implemented *by me*) before you are willing to
discuss the issue I wanted to discuss.

> The point you are missing is that we actually have stable users who
> essentially want *stable* system. Those people don't want to get
> testing packages unless absolutely necessary, and they'd rather wait
> for Python 3 to go stable than unmask the flag for the fun of it.

These users will not have PYTHON_TARGETS="python3_3",
so not forcing use.stable.mask on them makes no difference.
If they *should* have PYTHON_TARGETS="python3_3", either by
mistake or intentional, they will see that an unstable python is
pulled in, and they have to take actions.
It is better that they see this "mistake" than if just their
choice is tacitly undone.

>> Moreover, for use.stable.mask this cannot happen on a per-package basis.
>
> It's called package.use.stable.mask.

I was expecting that you cannot undo something in
package.use.stable.mask which was set in use.stable.mask
but I just tried, and you are right.

>> Perhaps one can introduce a better way to unmask use.stable.mask?
>
> Like what?

I thought about a new config-file, but after now knowing
that package.use.stable.mask can be used to undo use.stable.mask,
I am not so convinced whether this is really necessary.

>> Do you mean by "extra flags" again those of use.package.mask?
>> Then isn't this again an argument against use.package.mask at all?
>
> I mean stable-masked flags. So you get 2-in-1 with no clear indication
> that you got an extra unmask.

With the ~foo indication this would not happen.

> Then the user gets to rebuild python-exec which is a tiny C executable.
> Reverse dependencies are not rebuilt.

I could reproduce that libreoffice and some other consuments got [r]
when I marked all */python-exec as ~amd64 in package.acccept_keywords,
but it did not get reemerged when I did not do this.
Of course, it might be that something else is going on here, or it
might even be a bug in portage.

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Peter Stuge]

Michał Górny wrote:
> Did you ever do any serious package work, or are just discussing theory?

Michał, you're talking with a user. Please behave.

Make a concerted effort to put yourself in his situation. Talking
down to him ("did you ever do any serious work") is not helpful
for your image, for the user, or for the Gentoo project.


> Repoman is not a social tool. It's a technical dep checker

It's a developer tool. I've never run repoman myself and what little
I know about it suggests that I will never need to run repoman until
I have commit access to the portage tree. Even then it seems like a
nasty kludge that compensates for VCS limitations.

Because it's a developer tool you need to be doubleplus clear and
pedagogical whenever a user experience bubbles up to the tool (which
is unknown to us users).

I too spent some hours on fixing an out-of-the-blue python-exec mess
when I wanted to do some updates. For me that was a regression and I
hope that whoever cost me (and undoubtedly others) those hours at
least learned something from it that they didn't know before, if only
that this one user considered it a (for me) pointless regression.


> Do you see now what you are proposing?

You may remember that I do consider stable pointless. It is just an
euphemism for "old".

It makes the distribution into a time buffer, and a time sink, while
at least this upstream would much rather have direct connections to
users.

Taking another few steps back, I think it might be really cool if
Gentoo had so powerful tooling that as a user you wouldn't even
notice them. But that's some dream for the future perhaps. :)


> > The output can easily be improved:
> 
> If it can easily be improved, then why didn't *you* improve it yet?

You sound like an asshole here and I don't think you intend to. :\

You clearly want to encourage a user to contribute, but despite your
good intentions the words you choose have exactly the opposite effect
and if I were Zac I wouldn't be so happy.

You can communicate the same intended message using other words and
get the effect you want. It just requires thinking about who the
recipient is.


> We must be having different users.

I think Martin is a user, not a developer.


> we actually have stable users who essentially want *stable* system.

Yes, this is very true.

Maybe it is too ambitious to have the same portage tree for both use cases?

Not that it cannot be done, of course it can, but maybe the effort
required is just unneccessarily high. Maybe it would be easier to
make portage deal only with either kind of tree rather than both
trees in one, and to make some tooling to keep stabilization as easy
or maybe make it even easier than it is. Just an idea.


> And by using 'package.use' you 'undo' USE defaults in packages and
> global flag defaults, and... why do we have USE flags at all? We're
> just all undoing stuff anyway.

You're confusing things.

I dislike defaults when I have an opinion. I often have an opinion
and portage lets me express it well! <3

But while writing this mail I actually found a default that isn't
even documented which I disagree with, and it annoyed me because I
need to create an exception for it. (dev-qt/qtscript-4.8.5 USE=jit
which isn't mentioned in use.local.desc. File a bug? No, not now.)

That + in IUSE before the USE flag is surely intended to be helpful
but because I don't want jit (as wrong as I may be) it's annoying.

I can opt-out, but just as with marketing I would much rather opt-in,
as I have done with many hundred other USE flags, and many marketeers.


> Then the user gets to rebuild python-exec which is a tiny C executable.
> Reverse dependencies are not rebuilt.

I don't recall the details of my python-exec problem anymore, I
suspect it might have had to do with slots being introduced into
the package for the first time. I also had fun with libpng.


Rich Freeman wrote:
> Users who take advantage of new features in these kinds of states
> are going to run into problems.  That's just the cost of being on
> the cutting edge.

Why should a feature be allowed to cause problems? To me that just
means that the feature isn't finished yet, so why publish it?

Yes, I'm somewhat bug-intolerant.


//Peter

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

["Paweł Hajdan, Jr."]

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

On 11/13/13 8:05 AM, Martin Vaeth wrote:
> 1. A tiny change in the display: ~foo instead of (-foo)

I was thinking about same/similar thing: displaying USE flags masked in
general and USE flags masked for stable differently.

I'd in fact opt for ~(-foo) in this case, to indicate that the flag is
masked "()", that it is disabled "-", and that it's only for stable "~".

Note that then we can indicate stable forced flags (if any, I don't know
atm if it's even possible) with ~(foo).

> 2. A more severe change in the way how to unmask it:

It's not obvious to me whether this is better than just display changes.

It'd be great to have some specific examples (sorry if I missed some,
you can refer me to them), clearly pointing out the problem and the
advantages of different portage behavior.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Wed, Nov 13, 2013 at 12:03 PM, Peter Stuge <peter@stuge.se> wrote:
>
> Rich Freeman wrote:
>> Users who take advantage of new features in these kinds of states
>> are going to run into problems.  That's just the cost of being on
>> the cutting edge.
>
> Why should a feature be allowed to cause problems? To me that just
> means that the feature isn't finished yet, so why publish it?
>

Where were any of the multilib features published?

Rich

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Peter Stuge]

Rich Freeman wrote:
> >> Users who take advantage of new features in these kinds of states
> >> are going to run into problems.  That's just the cost of being on
> >> the cutting edge.
> >
> > Why should a feature be allowed to cause problems? To me that just
> > means that the feature isn't finished yet, so why publish it?
> 
> Where were any of the multilib features published?

Published as in made available to users. Were you refering to
Martin's use of emul-libs or something hypothetical? Sorry - I
might have lost track of the thread.


//Peter

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Wed, Nov 13, 2013 at 1:24 PM, Peter Stuge <peter@stuge.se> wrote:
> Rich Freeman wrote:
>> >> Users who take advantage of new features in these kinds of states
>> >> are going to run into problems.  That's just the cost of being on
>> >> the cutting edge.
>> >
>> > Why should a feature be allowed to cause problems? To me that just
>> > means that the feature isn't finished yet, so why publish it?
>>
>> Where were any of the multilib features published?
>
> Published as in made available to users. Were you refering to
> Martin's use of emul-libs or something hypothetical? Sorry - I
> might have lost track of the thread.

Experimental features are added to portage/eclasses/etc all the time.
The intent is to get more use out of them, get feedback, enable some
benefit, etc.  That doesn't mean that somebody who runs RAP or
hardened-to-the-max is going to have the same experience as somebody
who runs amd64 stable.

Gentoo lets you do stuff that few distros even make possible.  That
doesn't mean that it always makes all of those options "easy."  They
aren't "unsupported" - but the difference between "unsupported" and
"supported" in a volunteer distro is a bit hazy.  The more you step
off the beaten path, the more you're a guinea pig.

By all means report issues you find and help make Gentoo better, but
don't be upset if a bunch of volunteers came up with something
cutting-edge and it has a few bugs.  I mean, we're talking about
giving users the ability to build any package against any ABI and to
mix/match as you please.  Ten years ago we were happy to have a 32-bit
flash package.  No distro handles any of this stuff nearly as well as
we do, even if we still have some rough edges.

Rich

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Daniel Campbell]

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

On 11/13/2013 09:16 AM, Ian Stakenvicius wrote:
> On 13/11/13 09:55 AM, Thomas Kahle wrote:
>> On 11/13/2013 03:30 PM, Duncan wrote:
>>> Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as 
>>> excerpted:
>>> 
>>>> On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle 
>>>> <tomka@gentoo.org> wrote:
>>>>> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
>>>>>> On Wed, 13 Nov 2013 10:28:02 +0000 (UTC) Martin Vaeth 
>>>>>> <vaeth@mathematik.uni-wuerzburg.de> wrote:
>>>>>> 
>>>>>>> Hello.
>>>>>>> 
>>>>>>> The new "features" use.stable.mask and 
>>>>>>> package.use.stable.mask have turned maintaining
>>>>>>> systems with mixed ARCH and ~ARCH keywords into a
>>>>>>> nightmare:
>>>>>> 
>>>>>> They are considered unsupported by many; so, going down 
>>>>>> that path you need to be acquainted with Portage enough
>>>>>> to keep a consistent system.
>>>>> 
>>>>> This argument has come up several times, but is it valid?
>>>> 
>>>> Honestly, opinions vary on this one and I don't think it is
>>>> a productive path to go down.  I also feel that being able to
>>>> mix keywords is a big benefit of using Gentoo.  I'd rather
>>>> focus on practical ways to make this easier rather than
>>>> whether it is desirable.
>>>> 
>>>> That said, there are always going to be situations where
>>>> mixing keywords isn't practical.  You're not going to run
>>>> stable chromium against ~arch v8, or mixed keywords between
>>>> kdelibs and kwin, etc.
>>> 
>>> FWIW, I believe at least part of the confusion here is based
>>> on differing definitions of "supported".
> 
>> I agree.  Generally however, we should think Gentoo (or the open
>>  source ecosystem) more bazaar, less cathedral.  Libraries have 
>> interfaces, and they are supposed to be mixed and matched
>> according to the interface definitions.  We (Gentoo) should not
>> think of "Gentoo stable" as a fixed product like "iOS-7".  It has
>> come a long way, but philosophically I still think of Gentoo as a
>> kind of automated Linux-from-scratch (where you also mix and
>> match whatever you find on the Internets).
> 
>> In the end it boils down to what we mean by "supported".  For me
>>  "supported" does not mean "tested".  As you point out, testing 
>> every combination forbids itself.  Supported for me means that
>> the argument "you mixed stable and unstable" is not per se valid.
>>  There's a huge difference between
> 
>> You mixed unstable firefox with stable gcc
> 
>> and
> 
>> You mixed unstable X server with stable protocols.
> 
>> For me mixing the trees is supported in the sense that I would 
>> apply rational judgement to bugs.  If they are of the second
>> type, it can be said in a polite way that we as Gentoo can't do
>> anything about this combination not working.
> 
> 
> The term "supported" is a rather overloaded term which tends to
> mean different things in gentoo depending on the context that it is
> used (and who's using it), for sure.  It's also not analogous to
> "working" or "expected to work", at all, imo.
> 
> I wonder if it might be a good idea to have a discussion and reach 
> consensus on what the Gentoo (Developer) definition of "Supported" 
> should actually be, and document this somewhere so that ambiguity
> can be officially removed.
> 
> 
Not a developer, but when I see discussions about things that are
unsupported by the dev team, I think of it as "This is a special case
that's outside of our workflow and would add an exponential amount of
work for us if we tried to support it." Support, in this context, I
think refers to supporting bug reports and use cases. As mentioned
previously, it's impossible to account for every combination. If
developers stick to pure arch or pure ~arch, it's a hell of a lot
simpler to carry out the job, and I totally respect that.

I've had minimal problems mixing ~arch and arch, but based on what
I've read and my understanding of FOSS culture in general... "If you
go off the beaten path and break something, you get to keep the pieces."

Surely I'm not alone in that understanding. It's simple and closer to
pragmatism than any perceived malice or laziness that some may be
assuming about the developers.

~Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSg8t0AAoJEJUrb08JgYgHr44H/RUC4AXvAX2n1GoaITV2uI3Y
ZlKlpmyKk/rT0ucNAQhR+RUmZRuq+7Nuubxl6EH4eacfaqkkWLQjgsYJYUj49yFy
gGcXzsIfcWQg6DQcNGEvN2V9ICjI4Gsh1aQanKBORGPSomm3Nm7xsccXVYqTydIl
61lHHnWb1uECEA8Q+H10X3pw/Ila946LtL3uKUXuCooFmX6haAi5zLAGruMFH/1J
PCjApzSnNfMRFHyRJ5XgQTmpBVrk48ps9QGKqU26DBhrsbiTwocdSXq44oVh4YPK
43nxpjnVhMkc54xSbbXEp+QVjOYno9RhoxUfQCOj4WqE0N1PI0ZhWmas1NyW/wU=
=deQz
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[James Potts]

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

To be honest, I think that printing a summary of masked useflags which
contradict a user's settings in USE= at the end of the pretend/ask portion
of an emerge would be a step in the right direction.  Making it so that
portage bails with an error if package.use conflicts with
use.(package.)mask would also be helpful if this doesn't already happen.
 Not sure how much trouble this would be to add, tho, honestly.

--James



On Wed, Nov 13, 2013 at 12:56 PM, Daniel Campbell <lists@sporkbox.us> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/13/2013 09:16 AM, Ian Stakenvicius wrote:
> > On 13/11/13 09:55 AM, Thomas Kahle wrote:
> >> On 11/13/2013 03:30 PM, Duncan wrote:
> >>> Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as
> >>> excerpted:
> >>>
> >>>> On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle
> >>>> <tomka@gentoo.org> wrote:
> >>>>> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
> >>>>>> On Wed, 13 Nov 2013 10:28:02 +0000 (UTC) Martin Vaeth
> >>>>>> <vaeth@mathematik.uni-wuerzburg.de> wrote:
> >>>>>>
> >>>>>>> Hello.
> >>>>>>>
> >>>>>>> The new "features" use.stable.mask and
> >>>>>>> package.use.stable.mask have turned maintaining
> >>>>>>> systems with mixed ARCH and ~ARCH keywords into a
> >>>>>>> nightmare:
> >>>>>>
> >>>>>> They are considered unsupported by many; so, going down
> >>>>>> that path you need to be acquainted with Portage enough
> >>>>>> to keep a consistent system.
> >>>>>
> >>>>> This argument has come up several times, but is it valid?
> >>>>
> >>>> Honestly, opinions vary on this one and I don't think it is
> >>>> a productive path to go down.  I also feel that being able to
> >>>> mix keywords is a big benefit of using Gentoo.  I'd rather
> >>>> focus on practical ways to make this easier rather than
> >>>> whether it is desirable.
> >>>>
> >>>> That said, there are always going to be situations where
> >>>> mixing keywords isn't practical.  You're not going to run
> >>>> stable chromium against ~arch v8, or mixed keywords between
> >>>> kdelibs and kwin, etc.
> >>>
> >>> FWIW, I believe at least part of the confusion here is based
> >>> on differing definitions of "supported".
> >
> >> I agree.  Generally however, we should think Gentoo (or the open
> >>  source ecosystem) more bazaar, less cathedral.  Libraries have
> >> interfaces, and they are supposed to be mixed and matched
> >> according to the interface definitions.  We (Gentoo) should not
> >> think of "Gentoo stable" as a fixed product like "iOS-7".  It has
> >> come a long way, but philosophically I still think of Gentoo as a
> >> kind of automated Linux-from-scratch (where you also mix and
> >> match whatever you find on the Internets).
> >
> >> In the end it boils down to what we mean by "supported".  For me
> >>  "supported" does not mean "tested".  As you point out, testing
> >> every combination forbids itself.  Supported for me means that
> >> the argument "you mixed stable and unstable" is not per se valid.
> >>  There's a huge difference between
> >
> >> You mixed unstable firefox with stable gcc
> >
> >> and
> >
> >> You mixed unstable X server with stable protocols.
> >
> >> For me mixing the trees is supported in the sense that I would
> >> apply rational judgement to bugs.  If they are of the second
> >> type, it can be said in a polite way that we as Gentoo can't do
> >> anything about this combination not working.
> >
> >
> > The term "supported" is a rather overloaded term which tends to
> > mean different things in gentoo depending on the context that it is
> > used (and who's using it), for sure.  It's also not analogous to
> > "working" or "expected to work", at all, imo.
> >
> > I wonder if it might be a good idea to have a discussion and reach
> > consensus on what the Gentoo (Developer) definition of "Supported"
> > should actually be, and document this somewhere so that ambiguity
> > can be officially removed.
> >
> >
> Not a developer, but when I see discussions about things that are
> unsupported by the dev team, I think of it as "This is a special case
> that's outside of our workflow and would add an exponential amount of
> work for us if we tried to support it." Support, in this context, I
> think refers to supporting bug reports and use cases. As mentioned
> previously, it's impossible to account for every combination. If
> developers stick to pure arch or pure ~arch, it's a hell of a lot
> simpler to carry out the job, and I totally respect that.
>
> I've had minimal problems mixing ~arch and arch, but based on what
> I've read and my understanding of FOSS culture in general... "If you
> go off the beaten path and break something, you get to keep the pieces."
>
> Surely I'm not alone in that understanding. It's simple and closer to
> pragmatism than any perceived malice or laziness that some may be
> assuming about the developers.
>
> ~Daniel
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJSg8t0AAoJEJUrb08JgYgHr44H/RUC4AXvAX2n1GoaITV2uI3Y
> ZlKlpmyKk/rT0ucNAQhR+RUmZRuq+7Nuubxl6EH4eacfaqkkWLQjgsYJYUj49yFy
> gGcXzsIfcWQg6DQcNGEvN2V9ICjI4Gsh1aQanKBORGPSomm3Nm7xsccXVYqTydIl
> 61lHHnWb1uECEA8Q+H10X3pw/Ila946LtL3uKUXuCooFmX6haAi5zLAGruMFH/1J
> PCjApzSnNfMRFHyRJ5XgQTmpBVrk48ps9QGKqU26DBhrsbiTwocdSXq44oVh4YPK
> 43nxpjnVhMkc54xSbbXEp+QVjOYno9RhoxUfQCOj4WqE0N1PI0ZhWmas1NyW/wU=
> =deQz
> -----END PGP SIGNATURE-----
>
>

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

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Kent Fredric]

On 14 November 2013 09:21, James Potts <arek75@gmail.com> wrote:
> To be honest, I think that printing a summary of masked useflags which
> contradict a user's settings in USE= at the end of the pretend/ask portion
> of an emerge would be a step in the right direction.  Making it so that
> portage bails with an error if package.use conflicts with use.(package.)mask
> would also be helpful if this doesn't already happen.  Not sure how much
> trouble this would be to add, tho, honestly.


+1 to that, I was going to suggest something similar to help explain
what "~(foo)" means at least till people get used to it

e.g.
---
The Following Use Flags were user set, but ignored due to stability masks:
   dev-baz/quux: +foo -bar +baz

man emerge and grep for "stable use masks"
---

Or something. Maybe only shown with -v , or something so its not too
annoying if users are ok with ignoring it.

-- 
Kent

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Patrick Lauer]

On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:

> It's also worth pointing out that the whole reason why abi_x86_32 is
> {package.,}use.stable.masked is because trying to manage the partial
> transisition between emul-* and multilib-build dependencies

^^

Why is there a partial random transition with no roadmap, no coordination?

In terms of planning and communication this is a horribly stupid thing
(also ignoring the existing working portage-mulitilib stuff that was
mostly pushed forward by TommyD and now is ignored in an overlay)

A more clean way would have been to target each of the emul-x86
libraries, replace one completely with multilib-enabled libraries, fix
all consumers, *then* unmask that whole shebang at once.

Well, discussing it properly would also maybe have been a good idea, but
since this is now getting unilaterally hammered in it's mostly about
damage limitation now ...

> Note also that setting ABI_X86=32 globally isn't how it's supposed to
> be used; the point of this flag is for dependency resolution when a
> particular package requires it (ie, top-level package depends on
> app-cat/dep[abi_x86_32], portage --autounmask-write sets the necessary
> changes to /etc/portage/package.use).  But that's neither here nor there.
> 
I find that quite silly ...

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Wed, 13 Nov 2013 10:41:40 -0500
Mike Gilbert <floppym@gentoo.org> wrote:

> Let's talk about the development workflow we use for a minute:
> 
> [...]
> 
> This is not a completely social issue; there is a very real
> technical/QA issue that needs to be addressed on the development side.
> If you can figure that out, we can talk about changing the end-user
> experience.

The existence of use.stable.mask and the end-user experience however
have no one-on-one mapping (or should not have it); so, currently from
the user perspective it is easy to put the blame on use.stable.mask
without entirely being experienced with it from a developer perspective.

The blame being put there might be a consequence of something being
more problematic towards the interface with the user; some form of more
proper feature, notification or communication missing. I think that we
should rather look at what kind of options we have to improve things
there, because I really don't see a change to the existence or
functionality of use.stable.mask coming out of this thread.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-14, o godz. 07:49:55
Patrick Lauer <patrick@gentoo.org> napisał(a):

> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
> 
> > It's also worth pointing out that the whole reason why abi_x86_32 is
> > {package.,}use.stable.masked is because trying to manage the partial
> > transisition between emul-* and multilib-build dependencies
> 
> ^^
> 
> Why is there a partial random transition with no roadmap, no coordination?

https://wiki.gentoo.org/wiki/Multilib_porting_status

That's the closest thing to a roadmap.

So tell me, what you exactly want or need? Or is it just bare
complaining for the sake of complaining?

> A more clean way would have been to target each of the emul-x86
> libraries, replace one completely with multilib-enabled libraries, fix
> all consumers, *then* unmask that whole shebang at once.

We tried that. But in the end, it ended up masking new versions
of a whole lot of libraries waiting for remaining maintainers'
approval. And the maintainers that opposed the idea now complained that
it caused the packages to be masked long...

Feel free to convert all libraries, fix all consumers etc. We couldn't
achieve that with our manpower.

> Well, discussing it properly would also maybe have been a good idea, but
> since this is now getting unilaterally hammered in it's mostly about
> damage limitation now ...

And how is it possible to discuss anything properly in Gentoo?
On the mailing list where any serious thread is ignored, and silly
things and flamebaits are forked into three-four different, off-topic
threads like this one?

Don't tell me I didn't try to discuss it, that I didn't try to get
feedback. It's easy to complain almost one and a half year after
the original thread. Of course, AFAIR that thread went into the usual
'this seems like a shortened dup of what we were doing, you should
rather work for us'.

> > Note also that setting ABI_X86=32 globally isn't how it's supposed to
> > be used; the point of this flag is for dependency resolution when a
> > particular package requires it (ie, top-level package depends on
> > app-cat/dep[abi_x86_32], portage --autounmask-write sets the necessary
> > changes to /etc/portage/package.use).  But that's neither here nor there.
> > 
> I find that quite silly ...

You *can* set it globally. But it's going to give you more 32-bit stuff
than you will ever use, so waste your time and space. We try to support
both the 'lazy' user and one wanting fine-grained control over packages.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Patrick Lauer]

On 11/14/2013 01:13 PM, Michał Górny wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer <patrick@gentoo.org> napisał(a):
> 
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>>> It's also worth pointing out that the whole reason why abi_x86_32 is
>>> {package.,}use.stable.masked is because trying to manage the partial
>>> transisition between emul-* and multilib-build dependencies
>>
>> ^^
>>
>> Why is there a partial random transition with no roadmap, no coordination?
> 
> https://wiki.gentoo.org/wiki/Multilib_porting_status
> 
> That's the closest thing to a roadmap.

So just "fix it as problems appear and/or we have some spare time" ...

> So tell me, what you exactly want or need? Or is it just bare
> complaining for the sake of complaining?

Well, you accidentally cut out all references to TommyD's work again.
Almost as if you don't even want to discuss a working proper solution
that just doesn't have the ego hammering it in ...


>> A more clean way would have been to target each of the emul-x86
>> libraries, replace one completely with multilib-enabled libraries, fix
>> all consumers, *then* unmask that whole shebang at once.
> 
> We tried that. But in the end, it ended up masking new versions
> of a whole lot of libraries waiting for remaining maintainers'
> approval. And the maintainers that opposed the idea now complained that
> it caused the packages to be masked long...
There's this thing called overlay ;)
Once you have everything prepared commit it all masked.
A few days later if there's no obvious bug reports unmask it and duck.

> Feel free to convert all libraries, fix all consumers etc. We couldn't
> achieve that with our manpower.
So you just do it half-donkey'ed. Sigh.

Maybe ... you shouldn't do it if you can't properly finish it?

I mean, not like you cause a trail of destruction like the python-exec
fun, and such things ... maybe ... maybe ... you need to slow down and
plan more, and do your experiments in overlays.

Have fun,

Patrick

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>
> So just "fix it as problems appear and/or we have some spare time" ...

Have any problems appeared that impact anybody who hasn't tried to
take advantage of the new multilib features (ie modified their config
files/etc)?

>
> Well, you accidentally cut out all references to TommyD's work again.
> Almost as if you don't even want to discuss a working proper solution
> that just doesn't have the ego hammering it in ...

We get it - there are two competing approaches to multilib...  That's
perfectly fine - we can sort out which one works better once they both
work.  It would be more of a concern if maintainers were being asked
to maintain things twice, but as far as I'm aware the developers of
each of the competing approaches have been doing most of the work
themselves.

Of course, there could be issues I simply haven't heard of.

> There's this thing called overlay ;)
> Once you have everything prepared commit it all masked.
> A few days later if there's no obvious bug reports unmask it and duck.

I'm not sure an overlay is a good solution for a tree-wide change that
will take months to roll out.  It is great for testing the core
features with a small testing group, but the implementation is always
going to have to hit the whole tree and all its consumers with little
formal testing at that scale.

I guess my main question is what exactly is broken?  I haven't heard
of any large-scale problems with the new multilib rollout.  I'm sure
if I went looking for bugs I'd find them, but that's pretty much
par-for-the-course for Gentoo.  If I go install the latest gcc the day
after it gets added to the tree and enable some new flag that was just
introduced I'm going to find lots of packages that break.  That
doesn't mean that the new GCC wasn't ready for the tree - just that I
went looking for trouble, found it, and now I have the opportunity to
help out by filing bugs if what I actually did was reasonable.

Rich

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ben de Groot]

On 14 November 2013 13:13, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer <patrick@gentoo.org> napisał(a):
>
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>> > It's also worth pointing out that the whole reason why abi_x86_32 is
>> > {package.,}use.stable.masked is because trying to manage the partial
>> > transisition between emul-* and multilib-build dependencies
>>
>> ^^
>>
>> Why is there a partial random transition with no roadmap, no coordination?
>
> https://wiki.gentoo.org/wiki/Multilib_porting_status
>
> That's the closest thing to a roadmap.

Closest thing, yeah. But it doesn't really solve the problem. It's
basically a one-man show, but affecting a large part of the tree,
going ahead like a steam roller that can't be stopped, never mind the
road kill.

>> Well, discussing it properly would also maybe have been a good idea, but
>> since this is now getting unilaterally hammered in it's mostly about
>> damage limitation now ...
>
> And how is it possible to discuss anything properly in Gentoo?

That's because we have no proper leadership. We're an anarchistic
collection of people working at cross-purposes at the best of times.
There is no direction, and very little accountability.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Patrick Lauer]

On 11/14/2013 08:13 PM, Rich Freeman wrote:
> On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>
>> So just "fix it as problems appear and/or we have some spare time" ...
> 
> Have any problems appeared that impact anybody who hasn't tried to
> take advantage of the new multilib features (ie modified their config
> files/etc)?

Apart from me masking a few things because portage couldn't figure out a
way to a consistent state, and all that ...

I mean, not that we had lots of users in #gentoo WTFing all over the
place, or something. Oh wait, we did.

>>
>> Well, you accidentally cut out all references to TommyD's work again.
>> Almost as if you don't even want to discuss a working proper solution
>> that just doesn't have the ego hammering it in ...
> 
> We get it - there are two competing approaches to multilib...  That's
> perfectly fine - we can sort out which one works better once they both
> work.  

Given that one has been properly developed in an overlay, and one is now
forcefully hammered into the main tree, it's a fait accompli.

I have no idea how you think we can sort out anything with a pre-set
conclusion.

> It would be more of a concern if maintainers were being asked
> to maintain things twice, but as far as I'm aware the developers of
> each of the competing approaches have been doing most of the work
> themselves.
Apart from the maintainers that now have to figure out the funny bugs of
the in-tree work ... unlike a certain overlay. But I keep repeating
myself, which is redundantly redundant.

> 
> Of course, there could be issues I simply haven't heard of.
> 
>> There's this thing called overlay ;)
>> Once you have everything prepared commit it all masked.
>> A few days later if there's no obvious bug reports unmask it and duck.
> 
> I'm not sure an overlay is a good solution for a tree-wide change that
> will take months to roll out.  It is great for testing the core
> features with a small testing group, but the implementation is always
> going to have to hit the whole tree and all its consumers with little
> formal testing at that scale.

So instead of figuring out bugs the proper way ... we let users hit
them? I feel tempted to use the letters "A" and "Q" together.

Also, I could again redundantly point at a certain overlay.

Oh well. I guess I should complain less and package.mask more to express
my feelings...


Have a nice day,

Patrick

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 14 November 2013 13:13, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> And how is it possible to discuss anything properly in Gentoo?
>
> That's because we have no proper leadership. We're an anarchistic
> collection of people working at cross-purposes at the best of times.
> There is no direction, and very little accountability.

This seems to be an arrangement that everybody likes except when
somebody else does something differently than they would prefer...

We have a Council, and any issue can always be escalated there.  We
also have Comrel, which is a better starting point for cases
concerning individuals vs policies.

However, so far I haven't really seen any real indications of what the
concern is here.  32-bit software on amd64 has always been a kludge,
and if anything the latest multilib eclass seems to be less of a
kludge.  Apparently some argue that there is a better solution being
worked on, and that's great to hear.  What exactly is the problem?  If
the eclass were breaking things that weren't already broken and having
a real impact on ordinary systems I'd consider that a concern.  If it
is just breaking things that never worked before then I'd just call it
an experimental feature.

The problem with having top-down leadership in a volunteer-based
organization is that it tends to drive away anybody who doesn't agree
with the leader.  If a supreme leader said "mgorny has the right
solution to multilib - everybody is going to work to implement it"
that would probably cause more harm than good.  Everybody wants a
supreme leader until the leader backs something they oppose.

Rich

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Thu, Nov 14, 2013 at 7:30 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>
> Apart from me masking a few things because portage couldn't figure out a
> way to a consistent state, and all that ...

That is vague.  It may be true, but it does nothing to help anybody
understand what is going on.  I haven't had to mask anything, which
suggests that we're doing things differently.  That isn't to say that
you're doing things wrong, but it is hard to take complaints seriously
when they're vague.

>
> I mean, not that we had lots of users in #gentoo WTFing all over the
> place, or something. Oh wait, we did.

Honestly, I wish that a news item went out before it was implemented.
I'll agree that there was some end-user impact - I suddenly saw
portage outputting requests to set ABI on a few packages due to
dependency issues.  However, when I followed portage's instructions as
with any USE dependency issue everything "just worked."

>
> I have no idea how you think we can sort out anything with a pre-set
> conclusion.

What pre-set conclusion?  Nobody said that you can't work on multilib
in portage.  Nobody said you couldn't put it in the tree either, but I
would avoid namespace collision/etc unless done in a way that is
compatible with the eclass-based solution.  When we get to the point
where we have two options I'd be all for making it possible for users
to pick which one they want to use.

> Apart from the maintainers that now have to figure out the funny bugs of
> the in-tree work ... unlike a certain overlay. But I keep repeating
> myself, which is redundantly redundant.

I'll be the first to admit that I haven't seen these bugs, so I won't
say they aren't severe.  However, at least a few examples of the sorts
of things that could go wrong wouldn't hurt.  Again, this is vague.

> So instead of figuring out bugs the proper way ... we let users hit
> them? I feel tempted to use the letters "A" and "Q" together.
>
> Also, I could again redundantly point at a certain overlay.
>
> Oh well. I guess I should complain less and package.mask more to express
> my feelings...

Complaining isn't the problem.  The issue is that complaints aren't
helpful if they lack any detail or suggestions that are likely to be
acted upon.  Nobody is going to move the new eclass into an overlay,
and it is unlikely that anybody is going to spend a year tweaking
packages in an overlay just to find that they're all obsolete when it
comes time to merge them into the main tree.  Besides, it isn't like
an overlay would get much testing on this scale anyway.

Overlays are great places to work out issues on a small scale with a
few packages if you have multiple developers involved.  They don't
really accomplish much when you scale up, because your overlay is
always going to be out-of-date compared to the main tree.

Honestly, I'm not trying to pick sides here.  I just see complaints
about very new features, and my sense is that if those features aren't
working they should simply not be used.  I don't think I have that
variable set to anything but 64 on my stable amd64 system and I
haven't seen any problems with it recently.  If there are problems I'm
certainly interested in hearing about them.

Rich

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ben de Groot]

On 14 November 2013 20:32, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 14 November 2013 13:13, Michał Górny <mgorny@gentoo.org> wrote:
>>>
>>> And how is it possible to discuss anything properly in Gentoo?
>>
>> That's because we have no proper leadership. We're an anarchistic
>> collection of people working at cross-purposes at the best of times.
>> There is no direction, and very little accountability.
>
> This seems to be an arrangement that everybody likes except when
> somebody else does something differently than they would prefer...

Seems, maybe. I for one do not like it at all, and I do bring that up
from time to time. Others agree with me to various degrees. The
problem is that it's so damn hard to change anything structurally in
Gentoo.

> We have a Council, and any issue can always be escalated there.

As it is always happy to point out, Council doesn't see itself as
leadership, just as a supreme court of appeal, when everything else
seems to have failed. It likes to get involved as little as possible.

> We
> also have Comrel, which is a better starting point for cases
> concerning individuals vs policies.

This also displays little real leadership. It concerns itself with
conflict resolution, with various degrees of success. (I still have a
bad taste in my mouth from my past dealings with that institution.)

> However, so far I haven't really seen any real indications of what the
> concern is here.  32-bit software on amd64 has always been a kludge,
> and if anything the latest multilib eclass seems to be less of a
> kludge.

I vehemently disagree. The emul-* packages may be a hack, but they
work and cover the use cases we need. The new multilib eclass approach
is much more intrusive in many packages, introduces new levels of
complexity in ebuilds, with resulting new bugs and new behaviour that
confuses users, and adding maintenance costs. It does this for very
little gain. The great majority of our users doesn't need this
functionality.

The costs are higher than the benefits, in my opinion. Where are the
use cases for this high-cost solution that is being pushed upon us?

>  Apparently some argue that there is a better solution being
> worked on, and that's great to hear.  What exactly is the problem?  If
> the eclass were breaking things that weren't already broken and having
> a real impact on ordinary systems I'd consider that a concern.

If you'd care to look at the history of bugs due to multilib eclass
introduction in various packages, that's what you'd find.

> The problem with having top-down leadership in a volunteer-based
> organization is that it tends to drive away anybody who doesn't agree
> with the leader.  If a supreme leader said "mgorny has the right
> solution to multilib - everybody is going to work to implement it"
> that would probably cause more harm than good.  Everybody wants a
> supreme leader until the leader backs something they oppose.

But what's the alternative? Having a few dozen self-appointed leaders
doing whatever they want, and often taking things in opposing
directions. It's not top-down leadership, but rule of the strongest.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>>  I said
> As it is always happy to point out, Council doesn't see itself as
> leadership, just as a supreme court of appeal, when everything else
> seems to have failed. It likes to get involved as little as possible.

The last time I talked to Council she said that she doesn't like it
when you anthropomorphize her.

Certainly I stated in my manifesto that I believe that Council members
SHOULD be leaders, and should not limit their leadership of the distro
to casting votes.  That's why we're chatting on a list, and I'm not
sitting back waiting for you to put this issue on a Council agenda.

>
>> We
>> also have Comrel, which is a better starting point for cases
>> concerning individuals vs policies.
>
> This also displays little real leadership. It concerns itself with
> conflict resolution, with various degrees of success. (I still have a
> bad taste in my mouth from my past dealings with that institution.)

Well, that is the role of Comrel.  I don't expect it to decide whether
developers can touch each other's ebuilds to add systemd units to
them, etc.  However, if the Council establishes a policy then Comrel
should certainly take issue with devs that ignore that policy.  Comrel
certainly can show leadership when it comes to how it operates,
facilitating better relations in the community in general, etc.

>
> The costs are higher than the benefits, in my opinion. Where are the
> use cases for this high-cost solution that is being pushed upon us?

Where are the costs for this high-cost solution that you purport the
existence of?  Just what about this solution is difficult to maintain?
 I keep hearing that it is painful, but I haven't seen specific
examples of HOW it is painful.

>> The problem with having top-down leadership in a volunteer-based
>> organization is that it tends to drive away anybody who doesn't agree
>> with the leader.  If a supreme leader said "mgorny has the right
>> solution to multilib - everybody is going to work to implement it"
>> that would probably cause more harm than good.  Everybody wants a
>> supreme leader until the leader backs something they oppose.
>
> But what's the alternative? Having a few dozen self-appointed leaders
> doing whatever they want, and often taking things in opposing
> directions. It's not top-down leadership, but rule of the strongest.

When you have officially-appointed leaders they usually tend to be the
same people who would otherwise be the self-appointed leaders.  They
just have more power to kick everybody out who disagrees with them.
It is still the rule of the strongest.  How did Linus become the
leader of Linux?  He wrote it...

I used to get philosophical about things like this, but I think the
model Gentoo has is actually not a bad one.  In the end, stuff only
gets done if people write code.  Your power in any FOSS project really
comes down to your ability to write code or convince others to write
code on your behalf.  We can argue about what piece of software is
conceptually the best, but implemented software will almost always win
over the unimplemented competitor, unless the merits of the competitor
are such that people will flock behind it and actually implement it.

Rich

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ben de Groot]

On 14 November 2013 23:12, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>>>  I said
>> As it is always happy to point out, Council doesn't see itself as
>> leadership, just as a supreme court of appeal, when everything else
>> seems to have failed. It likes to get involved as little as possible.
>
> The last time I talked to Council she said that she doesn't like it
> when you anthropomorphize her.
>
> Certainly I stated in my manifesto that I believe that Council members
> SHOULD be leaders, and should not limit their leadership of the distro
> to casting votes.  That's why we're chatting on a list, and I'm not
> sitting back waiting for you to put this issue on a Council agenda.

That is nice of you, but many of your fellow councilmen (historically,
as well as currently) do not hold similar views, as was made painfully
clear to me a few years ago.

>>> We
>>> also have Comrel, which is a better starting point for cases
>>> concerning individuals vs policies.
>>
>> This also displays little real leadership. It concerns itself with
>> conflict resolution, with various degrees of success. (I still have a
>> bad taste in my mouth from my past dealings with that institution.)
>
> Well, that is the role of Comrel.  I don't expect it to decide whether
> developers can touch each other's ebuilds to add systemd units to
> them, etc.  However, if the Council establishes a policy then Comrel
> should certainly take issue with devs that ignore that policy.  Comrel
> certainly can show leadership when it comes to how it operates,
> facilitating better relations in the community in general, etc.
>
>>
>> The costs are higher than the benefits, in my opinion. Where are the
>> use cases for this high-cost solution that is being pushed upon us?
>
> Where are the costs for this high-cost solution that you purport the
> existence of?  Just what about this solution is difficult to maintain?
>  I keep hearing that it is painful, but I haven't seen specific
> examples of HOW it is painful.

See how much effort is expended on this, and how many maintainers are
being involved:
https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL+multilib

I was particularly hit by this as maintainer of freetype, see bugs
455070 and 459352 for some of the mess that could have been avoided.

>>> The problem with having top-down leadership in a volunteer-based
>>> organization is that it tends to drive away anybody who doesn't agree
>>> with the leader.  If a supreme leader said "mgorny has the right
>>> solution to multilib - everybody is going to work to implement it"
>>> that would probably cause more harm than good.  Everybody wants a
>>> supreme leader until the leader backs something they oppose.
>>
>> But what's the alternative? Having a few dozen self-appointed leaders
>> doing whatever they want, and often taking things in opposing
>> directions. It's not top-down leadership, but rule of the strongest.
>
> When you have officially-appointed leaders they usually tend to be the
> same people who would otherwise be the self-appointed leaders.  They
> just have more power to kick everybody out who disagrees with them.
> It is still the rule of the strongest.  How did Linus become the
> leader of Linux?  He wrote it...

At least there is one person in charge who sets a clear direction, and
is accountable.

> I used to get philosophical about things like this, but I think the
> model Gentoo has is actually not a bad one.

I guess we'll have to agree to disagree on this one then.

> In the end, stuff only
> gets done if people write code.  Your power in any FOSS project really
> comes down to your ability to write code or convince others to write
> code on your behalf.

No, it's more about your ability to commit and get away with it.

> We can argue about what piece of software is
> conceptually the best, but implemented software will almost always win
> over the unimplemented competitor, unless the merits of the competitor
> are such that people will flock behind it and actually implement it.
>
> Rich
>

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> I was particularly hit by this as maintainer of freetype, see bugs
> 455070 and 459352 for some of the mess that could have been avoided.

Looks like 455070 was the source of problems there (the other is just
a tracker with the aftermath).  The package had no maintainer at the
time, only a herd (per cvs).  There was a request in the bug for
whether it was suitable to deploy to production.  Somebody associated
with the herd gave a thumbs-up, apparently (I can only say that based
on your comment - I have no idea how that was communicated).  Then
something went wrong.  Since it caused problems, it was masked.  Those
who run ~arch should be thanked for saving the stable users from
potential breakage!

I'm not sure what should have been done differently.  If the package
maintainer (in this case a herd) says that something is good to go,
why would anybody assume that it wasn't?  You suggested testing in an
overlay 20 days earlier, but you weren't in any particularly
privileged position at the time (you were presumably just another
maintainer of the herd).

I'm not pointing fingers here.  This was apparently a
miscommunication, and part of the cause was a failure to document that
there was a primary maintainer of the package (something which was
subsequently corrected).  Michał did offer to just maintain the status
quo on that package instead of migrating it, and apparently he thought
he had the all-clear to migrate it anyway.

Michał did add the multilib project as a co-maintainer, taking
responsibility for dealing with the multilib-related issues long-term.
 In my mind this is the sort of things projects should do.

I'm sure there were other issues, but issues will happen when projects
make changes.  That's just the way things roll around here.  If Michał
just committed a change to a package without conferring with the
maintainer at all or giving significant notice, I'd feel differently.
I think we just need to learn and move forward, and from the looks of
things we have.  Gentoo always has been a fairly "disruptive" distro,
though it has settled down of late.  I don't think we're erring on the
side of breaking systems too often right now, though I'm always for
preventing that as long as it doesn't require ossification.

(Just a note - this is all based on what I could piece together from
cvs and bugzilla.  I'm sure those who were personally involved could
contribute more detail. I'm not sure it is necessary that do so, but
I'll gladly defer to those with firsthand knowledge.)

>> In the end, stuff only
>> gets done if people write code.  Your power in any FOSS project really
>> comes down to your ability to write code or convince others to write
>> code on your behalf.

> No, it's more about your ability to commit and get away with it.

So, I'm 100% for what Donnie said and in general I tend to lean
towards saying "thanks, but no thanks" when a heavy contributor is
driving everybody nuts.  However, the reality is that those who commit
more also tend to be allowed to get away with committing more.  That's
just human nature - we all like our free toys and we're reluctant to
take too much objection when we're slapped around a little by the guy
who is giving us the free toys.  There needs to be a balance, and from
the sound of things Markos is looking to step in and adjust the
balance if it gets out of line.  Honestly, I just wish everybody would
do what they can to make his job easier, and I say that without
pointing my fingers in any direction.  I think we have a really great
thing going here...

Rich

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-14, o godz. 20:03:36
Patrick Lauer <patrick@gentoo.org> napisał(a):

> On 11/14/2013 01:13 PM, Michał Górny wrote:
> > https://wiki.gentoo.org/wiki/Multilib_porting_status
> > 
> > That's the closest thing to a roadmap.
> 
> So just "fix it as problems appear and/or we have some spare time" ...

You could tell that. Or you could notice that this was specifically
designed as an unobtrusive solution with possibility of gradual
migration and backwards compatibility.

> > So tell me, what you exactly want or need? Or is it just bare
> > complaining for the sake of complaining?
> 
> Well, you accidentally cut out all references to TommyD's work again.
> Almost as if you don't even want to discuss a working proper solution
> that just doesn't have the ego hammering it in ...

'Proper' is the keyword. The solution you mention has many issues that
I listed more than once, and is far from unobtrusive, clear
or explicit. It's supposedly working, yes, but it is nowhere near
production-ready.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Thomas Sachau]

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

Rich Freeman schrieb:
> On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>
>> So just "fix it as problems appear and/or we have some spare time" ...
> 
> Have any problems appeared that impact anybody who hasn't tried to
> take advantage of the new multilib features (ie modified their config
> files/etc)?
> 
>>
>> Well, you accidentally cut out all references to TommyD's work again.
>> Almost as if you don't even want to discuss a working proper solution
>> that just doesn't have the ego hammering it in ...
> 
> We get it - there are two competing approaches to multilib...  That's
> perfectly fine - we can sort out which one works better once they both
> work.  It would be more of a concern if maintainers were being asked
> to maintain things twice, but as far as I'm aware the developers of
> each of the competing approaches have been doing most of the work
> themselves.
> 
> Of course, there could be issues I simply haven't heard of.

There is a pretty big issue/difference here:

- multilib-portage was planned to add features with a future EAPI
version, so in the end needs agreement from maintainers of package
managers, the pms team and the council. If anyone from those groups only
claims "you wrote so much, but i dont understand it, write more", then
it can be a very long time to get it into the main tree (also this
usually means it is well reviewed and tested)

- the new multilib eclasses dont need any ok from anyone, so they have
been added instantly after first creation of a draft. So after addition
(also they only support a subset of the things supported by
multilib-portage) ebuilds are now converted to use them for multilib
support. Noone will opt to revert/convert those changes once
multilib-portage would be ready, so the eclasses win simply by the lower
entrance barrier


In the end multilib-portage will likely end as a portage-only feature
allowing multilib-support on packages without the need to change ebuilds
(it also has support for wrapping binaries per ABI, but this will
hopefully at some point also go into the eclasses).

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ciaran McCreesh]

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

On Thu, 14 Nov 2013 20:07:39 +0100
Thomas Sachau <tommy@gentoo.org> wrote:
> - multilib-portage was planned to add features with a future EAPI
> version, so in the end needs agreement from maintainers of package
> managers, the pms team and the council. If anyone from those groups
> only claims "you wrote so much, but i dont understand it, write
> more", then it can be a very long time to get it into the main tree
> (also this usually means it is well reviewed and tested)

That's only a problem if you've got a horribly complicated feature
where you can't remember yourself what you changed to make it work or
how or why you implemented it.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Patrick Lauer]

On 11/15/2013 01:51 AM, Michał Górny wrote:

>>> So tell me, what you exactly want or need? Or is it just bare
>>> complaining for the sake of complaining?
>>
>> Well, you accidentally cut out all references to TommyD's work again.
>> Almost as if you don't even want to discuss a working proper solution
>> that just doesn't have the ego hammering it in ...
> 
> 'Proper' is the keyword. The solution you mention has many issues that
> I listed more than once, and is far from unobtrusive, clear
> or explicit. It's supposedly working, yes, but it is nowhere near
> production-ready.

But at least the maintainer followed the protocol and did ask for
feedback, did not just hammer it into the main tree etc.

(Said maintainer was told to properly document AND DICSUSS it, or else
... one wonders why there's so much divergence between these two attempts)

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Patrick Lauer]

On 11/15/2013 03:35 AM, Ciaran McCreesh wrote:
> On Thu, 14 Nov 2013 20:07:39 +0100
> Thomas Sachau <tommy@gentoo.org> wrote:
>> - multilib-portage was planned to add features with a future EAPI
>> version, so in the end needs agreement from maintainers of package
>> managers, the pms team and the council. If anyone from those groups
>> only claims "you wrote so much, but i dont understand it, write
>> more", then it can be a very long time to get it into the main tree
>> (also this usually means it is well reviewed and tested)
> 
> That's only a problem if you've got a horribly complicated feature
> where you can't remember yourself what you changed to make it work or
> how or why you implemented it.
> 
... or if people shift the goalpost so much that you don't even remember
what game is being played

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Matt Turner]

On Wed, Nov 13, 2013 at 2:28 AM, Martin Vaeth
<vaeth@mathematik.uni-wuerzburg.de> wrote:
> The new "features" use.stable.mask and package.use.stable.mask
> have turned maintaining systems with mixed ARCH and ~ARCH keywords
> into a nightmare:

I agree. I have helped two friends convert to Gentoo recently (one
used it a few years ago). They both came from Arch, and one told me
that before he resumed using Gentoo recently he considered these two
distros in the same category in terms of difficulty of use and
maintenance. After using it for a month, he's now convinced that
Gentoo is clearly the most difficult to use.

I'm inclined to agree, and I think in large part recently it's because
of use.stable.mask and package.use.stable.mask. These really are a
nightmare for users. Heck, they're really a nightmare for me and I've
been using Gentoo for nine years and feel like I have a pretty good
ability to decipher portage's error messages.

I think most of the confusion is caused by the necessity to put a
*stable* package atom into package.keywords to unmask a *USE* flag.
(Am I doing something wrong that would prevent 'x11-proto/kbproto
-abi_x86_32' in /etc/portage/package.use.stable.mask from
un-stable-masking the abi_x86_32 USE flag for kbproto?)

And then in addition, we did really weird things like stabilizing
package versions whose only difference from the previous is that it
supports multilib (e.g., kbproto-1.0.6 vs kbproto-1.0.6-r1). Except
that it's package.use.stable.mask'd. So you have to keyword a stable
package to get its only defining feature. (Why did we stabilize it in
the first place?)

Portage correctly shows that unstable USE flags are masked by printing
parenthesis around them, like use.mask'd flags, but the error messages
are really unhelpful. Take for instance dropping the stable
=x11-proto/kbproto-1.0.6-r1 from package.keywords, in order implicitly
mask the abi_x86_32. Attempting to merge =x11-proto/kbproto-1.0.6-r1
results in:

x11-proto/kbproto:0

  (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by
    x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
required by (x11-libs/libX11-1.6.2::gentoo, installed)
    x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
required by (x11-libs/libXt-1.1.4::gentoo, installed)

There's a single problem. It can't enable abi_x86_32. Why didn't it
just say that?

You could even go beyond this and explain why it can't do it, but at
this point I'd settle for a concise explanation of *what* it can't do.

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Kent Fredric]

On 15 November 2013 17:56, Matt Turner <mattst88@gentoo.org> wrote:
> After using it for a month, he's now convinced that
> Gentoo is clearly the most difficult to use.
>
> I'm inclined to agree,


I'd have to disagree there slightly, arch is more easy to use if you
stick to the core set, the binary packages ... as is debian.

But if you verge outside that set, arch quickly becomes a headache,
AUR may have lots of contribution, but its nowhere near the quality we
have of even some of our worse quality overlays, and the arch
toolchain lacks lots of features ebuild authors have come to rely on.

This means if you use arch's equivalent of our overlays, you'll spend
much time fixing up  broken syntax in AUR packages.

I mean, sure, its "simpler", but at the same time, it does so by
simply cauterizing out the extra complexity, making it impossible for
end users to even opt for the complex or different behaviours, by
choosing one for them, and not informing them at all of that choice.

So that argument mostly boils down to "useflags add complexity for
people who aren't used to them, or aren't interested in them".

-- 
Kent

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ben de Groot]

On 15 November 2013 01:32, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> I was particularly hit by this as maintainer of freetype, see bugs
>> 455070 and 459352 for some of the mess that could have been avoided.
>
> Looks like 455070 was the source of problems there (the other is just
> a tracker with the aftermath).  The package had no maintainer at the
> time, only a herd (per cvs).  There was a request in the bug for
> whether it was suitable to deploy to production.  Somebody associated
> with the herd gave a thumbs-up, apparently (I can only say that based
> on your comment - I have no idea how that was communicated).  Then
> something went wrong.  Since it caused problems, it was masked.  Those
> who run ~arch should be thanked for saving the stable users from
> potential breakage!
>
> I'm not sure what should have been done differently.  If the package
> maintainer (in this case a herd) says that something is good to go,
> why would anybody assume that it wasn't?  You suggested testing in an
> overlay 20 days earlier, but you weren't in any particularly
> privileged position at the time (you were presumably just another
> maintainer of the herd).

I don't really want to bring up this episode again, but it is a
telling example, which you asked for.

As can be seen from the ChangeLog, I was the primary maintainer. As a
member of the herd I didn't feel it necessary to assert any kind of
"privilege" any other way. I had already said "no, or at least wait"
but that was circumvented by asking another herd member who hadn't
touched the package in years. It would have been nice were I asked for
my okay before making any changes.

And as can be seen, the mess I feared for indeed took place. This
could have been prevented, in my opinion, had this seen more extensive
testing in an overlay.

And this is exactly why I am now more weary for the next package about
to be mangled: cairo (bug 488672).

I am even tempted to undo the multilib changes to freetype, since it
is still causing trouble (just search for freetype bugs and see how
often multilib pops up).

> I'm not pointing fingers here.  This was apparently a
> miscommunication, and part of the cause was a failure to document that
> there was a primary maintainer of the package (something which was
> subsequently corrected).  Michał did offer to just maintain the status
> quo on that package instead of migrating it, and apparently he thought
> he had the all-clear to migrate it anyway.
>
> Michał did add the multilib project as a co-maintainer, taking
> responsibility for dealing with the multilib-related issues long-term.
>  In my mind this is the sort of things projects should do.

Indeed, but more communication with the current actual maintainers of
the package in question should also be part of that.

> I'm sure there were other issues, but issues will happen when projects
> make changes.  That's just the way things roll around here.  If Michał
> just committed a change to a package without conferring with the
> maintainer at all or giving significant notice, I'd feel differently.
> I think we just need to learn and move forward, and from the looks of
> things we have.  Gentoo always has been a fairly "disruptive" distro,
> though it has settled down of late.  I don't think we're erring on the
> side of breaking systems too often right now, though I'm always for
> preventing that as long as it doesn't require ossification.
>
> (Just a note - this is all based on what I could piece together from
> cvs and bugzilla.  I'm sure those who were personally involved could
> contribute more detail. I'm not sure it is necessary that do so, but
> I'll gladly defer to those with firsthand knowledge.)
>
>>> In the end, stuff only
>>> gets done if people write code.  Your power in any FOSS project really
>>> comes down to your ability to write code or convince others to write
>>> code on your behalf.
>
>> No, it's more about your ability to commit and get away with it.
>
> So, I'm 100% for what Donnie said and in general I tend to lean
> towards saying "thanks, but no thanks" when a heavy contributor is
> driving everybody nuts.  However, the reality is that those who commit
> more also tend to be allowed to get away with committing more.  That's
> just human nature - we all like our free toys and we're reluctant to
> take too much objection when we're slapped around a little by the guy
> who is giving us the free toys.  There needs to be a balance, and from
> the sound of things Markos is looking to step in and adjust the
> balance if it gets out of line.  Honestly, I just wish everybody would
> do what they can to make his job easier, and I say that without
> pointing my fingers in any direction.  I think we have a really great
> thing going here...
>
> Rich
>

Markos has shown initiative and good ideas, so I'm looking forward to
positive changes.

I am also cautiously optimistic about a renewed QA team, which could
be involved more in this kind of issues.

As I see it now, with respect to multilib, we have three competing
solutions, but not a clear direction which way we want to go as a
distro:

1: emul-* packages
2: multilib-portage
3: multilib.eclass

I would like to vote for option 1, as it is the least intrusive and
does what we need. If it is really felt we need a more complete
solution, then my vote would be for 2, since 3 is too intrusive and
more likely to break or complicate stuff for normal users.

If you say council should take more of a leadership role, then maybe
this issue can be decided by council and a clear direction be taken by
the distro as a whole? Then those who oppose the choice made can
either put up or shut up, and we can all work at implementing the
chosen solution.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ulrich Mueller]

>>>>> On Fri, 15 Nov 2013, Ben de Groot wrote:

> As I see it now, with respect to multilib, we have three competing
> solutions, but not a clear direction which way we want to go as a
> distro:

> 1: emul-* packages
> 2: multilib-portage
> 3: multilib.eclass

> I would like to vote for option 1, as it is the least intrusive and
> does what we need. If it is really felt we need a more complete
> solution, then my vote would be for 2, since 3 is too intrusive and
> more likely to break or complicate stuff for normal users.

Option 1 is not a solution, but a workaround. It has served us,
but IMHO its replacement is overdue. Just to give an example,
stable emul-linux-x86-xlibs suffers from several security issues
(bug 471098, A1/critical severity) since half a year.

Besides, distributing pre-compiled binary packages seems very
un-Gentoo-ish.

Not sure why you think that option 3 is more intrusive than option 2.
What can be more intrusive than requiring a modified package manager?

Ulrich

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Duncan]

Ulrich Mueller posted on Fri, 15 Nov 2013 08:13:47 +0100 as excerpted:

>>>>>> On Fri, 15 Nov 2013, Ben de Groot wrote:
> 
>> As I see it now, with respect to multilib, we have three competing
>> solutions, but not a clear direction which way we want to go as a
>> distro:
> 
>> 1: emul-* packages 2: multilib-portage 3: multilib.eclass
> 
>> I would like to vote for option 1, as it is the least intrusive and
>> does what we need. If it is really felt we need a more complete
>> solution, then my vote would be for 2, since 3 is too intrusive and
>> more likely to break or complicate stuff for normal users.
> 
> Option 1 is not a solution, but a workaround. It has served us,
> but IMHO its replacement is overdue. Just to give an example,
> stable emul-linux-x86-xlibs suffers from several security issues (bug
> 471098, A1/critical severity) since half a year.
> 
> Besides, distributing pre-compiled binary packages seems very
> un-Gentoo-ish.

Indeed.  From amd64's gentoo roots the gentoo/amd64 people considered 
emul-* a sort-of-embarrassing workaround for a distro such as gentoo, 
where for many the biggest /point/ is building from sources in ordered to 
enable more user-level customization.  Basically it was and remains a 
case of saying "Umm... we believe in building from source, except don't 
look too closely because in some cases we don't."

If people are willing to accept emul-* because it's "easier", why bother 
with gentoo at all, because binary distros that make all compile-time 
choices for the user are even /easier/?

So indeed, emul-* is a workaround, and quite a hacked up one for a distro 
such as gentoo at that, NOT a solution.

However, I'd replace it as a solution with the (32-bit) chroot solution, 
which I use here along with no-multilib for my main amd64 system, except 
that I extended the chroot to build the full image (including kernel, 
system daemons, grub, etc, that wouldn't need built on a simple 32-bit 
chroot) so as to be able to transfer it first via USB thumbdrive and 
eventually via SSH to my 32-bit netbook, which boots from it.  (I could 
thus make the 32-bit image on my main machine bootable as well, with 
trivial effort, letting me dual-boot it, but I've had no reason to do so.)

The 32-bit chroot solution is indeed a full gentoo-level solution, 
already documented, requiring no changes to the tree or to PMs, since it 
uses the existing x86 arch profiles just as they come.

So:

1: emul-* packages[1]
2: multilib-portage
3: multilib.eclass
4: chroot[2]

[1] hacked up workaround, not a proper gentoo level solution.
[2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or either 
one for x86-32, or some other combination for other archs.

> Not sure why you think that option 3 is more intrusive than option 2.
> What can be more intrusive than requiring a modified package manager?

If the perspective is that of a "plain" no-multilib user (even one like 
me using the 32-bit chroot solution), or even a standard multilib user 
satisfied with the emul-* workaround, then option 3 is very intrusive 
indeed, since it has already triggered quite a few package updates with 
the only purpose being introduction of a feature these users aren't 
particularly interested in.  To these folks, options 2 and 4 are 
preferred, since for the most part the only folks affected are those who 
will actually be using the feature.

Indeed, while option 2 has required some mostly trivial patches and I 
think a whole EAPI, option 4 requires none of that, operating with the 
existing tree just as it is.  It'd be a rare bug indeed that affected a 
chroot solution but didn't affect other users of the target arch, 
especially since gentoo's installation model already involves chroots, so 
bugs involving chroots in @system at least, by /definition/ involve the 
affected arch, and should be caught and worked out by releng as a result.

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Patrick Lauer]

On 11/15/2013 03:13 PM, Ulrich Mueller wrote:
>>>>>> On Fri, 15 Nov 2013, Ben de Groot wrote:
> 
>> As I see it now, with respect to multilib, we have three competing
>> solutions, but not a clear direction which way we want to go as a
>> distro:
> 
>> 1: emul-* packages
>> 2: multilib-portage
>> 3: multilib.eclass
> 
>> I would like to vote for option 1, as it is the least intrusive and
>> does what we need. If it is really felt we need a more complete
>> solution, then my vote would be for 2, since 3 is too intrusive and
>> more likely to break or complicate stuff for normal users.
> 
> Option 1 is not a solution, but a workaround. It has served us,
> but IMHO its replacement is overdue. Just to give an example,
> stable emul-linux-x86-xlibs suffers from several security issues
> (bug 471098, A1/critical severity) since half a year.
That's not an argument for or against anything, that just shows that we
don't even have enough devs caring for the "easiest" method.

Maybe ... dunno ... maybe that should be more automated so that a single
trigger could generate the packages.

> 
> Besides, distributing pre-compiled binary packages seems very
> un-Gentoo-ish.

Indeed.
> Not sure why you think that option 3 is more intrusive than option 2.
> What can be more intrusive than requiring a modified package manager?
What's intrusive? We tolerate EAPI5, @preserved-rebuild and other
package manager mods too ...

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman]

On Fri, Nov 15, 2013 at 1:53 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>
> I don't really want to bring up this episode again, but it is a
> telling example, which you asked for.

I appreciate that.  I did ask for an example.  I'll also limit my
comments just to things that I think are more helpful moving forward.

>
> As can be seen from the ChangeLog, I was the primary maintainer.

Depends on your definition of maintainer.  If you define maintainer as
somebody who has actually been doing work on a package, then you were.
 If you define it as the person listed in metadata.xml, then you
weren't.

Ideally those should match, so that when projects have to go running
around the tree making changes they don't have to read between the
lines to figure out who is the right contact for any particular
package.

They match now, which is good.

>
> I am even tempted to undo the multilib changes to freetype, since it
> is still causing trouble (just search for freetype bugs and see how
> often multilib pops up).

Well, make sure you talk to the OTHER maintainer for that package,
which is the multilib team, before doing that.  You don't own the
package - you just help to maintain it.  I don't want to rehash the
thread from last summer - I do appreciate your feelings and I'm trying
to find a balance.  I want to appreciate the fact that maintainers
have the largest investment in their packages, but at the same time
those working on projects are investing in Gentoo as well.

>>
>> Michał did add the multilib project as a co-maintainer, taking
>> responsibility for dealing with the multilib-related issues long-term.
>>  In my mind this is the sort of things projects should do.
>
> Indeed, but more communication with the current actual maintainers of
> the package in question should also be part of that.

You're both "actual" maintainers now.  Certainly I agree that you
should be talking to each other.  :)  I'd hope that things are going
better now, but if they aren't I'd hope that Comrel would provide some
assistance here.

>
> I am also cautiously optimistic about a renewed QA team, which could
> be involved more in this kind of issues.

I tend to agree here, but their role isn't to pick winners so much as
to defend the general integrity of the tree.  I think the challenge is
figuring out how good, "good enough," is before these packages end up
in ~arch (which IS intended for TESTING packages, but packages that
are fairly likely to work with some maintainer testing already).

> If you say council should take more of a leadership role, then maybe
> this issue can be decided by council and a clear direction be taken by
> the distro as a whole? Then those who oppose the choice made can
> either put up or shut up, and we can all work at implementing the
> chosen solution.

Should we pick an init system while we're at it?  :)

Honestly, I don't think we can really choose anything at this point as
none of the solutions are really fully-baked.  If the Council simply
pronounced support for one of them the only result would be that
people might stop working on the other two, with no further progress
on the chosen one.  Then if that one dies on the vine we're stuck.

I do have thoughts around things that could be improved, but I don't
think either of the new options are at the point where they make
sense.  Both options really have to progress further on their own
before we can think about standardizing/etc.

Rich

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/11/13 02:13 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 15 Nov 2013, Ben de Groot wrote:
> 
>> As I see it now, with respect to multilib, we have three
>> competing solutions, but not a clear direction which way we want
>> to go as a distro:
> 
>> 1: emul-* packages 2: multilib-portage 3: multilib.eclass
> 
>> I would like to vote for option 1, as it is the least intrusive
>> and does what we need. If it is really felt we need a more
>> complete solution, then my vote would be for 2, since 3 is too
>> intrusive and more likely to break or complicate stuff for normal
>> users.
> 
> Option 1 is not a solution, but a workaround. It has served us, but
> IMHO its replacement is overdue. Just to give an example, stable
> emul-linux-x86-xlibs suffers from several security issues (bug
> 471098, A1/critical severity) since half a year.
> 
> Besides, distributing pre-compiled binary packages seems very 
> un-Gentoo-ish.
> 
> Not sure why you think that option 3 is more intrusive than option
> 2. What can be more intrusive than requiring a modified package
> manager?

I concurr -- option #1 has existed for some time but it's entirely a
workaround rather than a solution.

Option 2 and Option 3, though, I don't see as having to be a competing
system -- to me they provide for different goals (most of which
overlap, but still).

Multilib-portage provides the ability to build an entire userland in
as many ABIs as can be supported -- bins, libs, the whole deal; no
matter if the in-tree ebuilds have an alt-ABI specification or not.

The multilib eclasses allow any ebuild that needs to, to depend on a
non-native-ABI library and forces any package manager to work it out
via use flags.

#3 works for everyone in a more limited scope than #2 (just libs,
generally with the goal of only including the few libs the in-tree
consumers actually need).  #2 provides users that want it with a
specific PM to manage their system, as alternative to the other PMs
out there.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKGLzgACgkQ2ugaI38ACPCrkgD+JNG1iF/oGh/5gXtqhTXlhHGL
A4tM6dbfZxmt793CTGwA+wercYN3gwb10GHyxs0bUMkime+cWDFpPphjPHU9BAtn
=BPc1
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/11/13 06:08 AM, Duncan wrote:
> [2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or
> either one for x86-32, or some other combination for other archs.

Well, not really -- an x86 toolchain can't build for amd64 or x32 ,
you need a crossdev for that.  I don't think either multilib-portage
or the multilib-eclass solution are going to be substantive enough to
incorporate crossdev building directly into the package manager.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKGMCAACgkQ2ugaI38ACPBGWwD/QaFE626C44E8N1d/6aupdfsh
vHlKe9xmtfcANRV8QlkA/0pt9P9XYsNahnU/hJvpwSg3QGTQlB3yf3npTuZ8BkiL
=ImMI
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Duncan]

Ian Stakenvicius posted on Fri, 15 Nov 2013 09:30:56 -0500 as excerpted:

> On 15/11/13 06:08 AM, Duncan wrote:
>> [2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or
>> either one for x86-32, or some other combination for other archs.
> 
> Well, not really -- an x86 toolchain can't build for amd64 or x32 , you
> need a crossdev for that.  I don't think either multilib-portage or the
> multilib-eclass solution are going to be substantive enough to
> incorporate crossdev building directly into the package manager.

Good point.  I let my efforts to be inclusive get the best of my common 
sense. =:^(

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Peter Stuge]

Matt Turner wrote:
> I think in large part recently it's because of use.stable.mask and
> package.use.stable.mask. These really are a nightmare for users.
..
> I think most of the confusion is caused by the necessity to put a
> *stable* package atom into package.keywords to unmask a *USE* flag.

A lot can be learned just from the filenames:

use.stable.mask
package.use.stable.mask

The latter indicates that this concept has no less than four dimensions.

Let's enumerate and associate:

1. use - USE flags - no problem, Gentoo users either love USE flags or leave
2. stable - arch vs. ~arch - no problem, even installation docs describe it
3. mask - masked packages - OK, at some point people encounter masked packages
4. package - per-package stuff - like with /etc/portage/package.use

How stable and mask interact with USE is absolutely unclear and usability
of this is very close to zero.


//Peter

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/11/13 10:54 AM, Peter Stuge wrote:
> Matt Turner wrote:
>> I think in large part recently it's because of use.stable.mask
>> and package.use.stable.mask. These really are a nightmare for
>> users.
> ..
>> I think most of the confusion is caused by the necessity to put
>> a *stable* package atom into package.keywords to unmask a *USE*
>> flag.
> 
> A lot can be learned just from the filenames:
> 
> use.stable.mask package.use.stable.mask
> 
> The latter indicates that this concept has no less than four
> dimensions.
> 
> Let's enumerate and associate:
> 
> 1. use - USE flags - no problem, Gentoo users either love USE flags
> or leave 2. stable - arch vs. ~arch - no problem, even installation
> docs describe it 3. mask - masked packages - OK, at some point
> people encounter masked packages 4. package - per-package stuff -
> like with /etc/portage/package.use
> 
> How stable and mask interact with USE is absolutely unclear and
> usability of this is very close to zero.

Well, reordering this a bit:

1 - package: so this is per-package.
2 - use: so this has to do with use flags, per package
3 - stable: so this has to do with stable systems' use flags, per package
4 - mask: so this is disallowing something on stable systems' use
flags, per package.

So I don't think this is entirely unclear.

I suppose it might be a bit more clear if it was called
'package.stable.use.mask', or the ideal english version of
'stable.package.use.mask', but i think renaming it at this point
doesn't really provide that much of an advantage and definitely
doesn't change what it does.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKGRkUACgkQ2ugaI38ACPAu+gD/U6rExYFTC7fUMFIuQgbgJwRn
I0sA9NSixk6gtVj8E8IA/i1jzlQnkjHQFnHw3qHnTtdUGpJHFn/0saxItbn6ieE9
=+7UA
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Thu, 14 Nov 2013 20:56:32 -0800
Matt Turner <mattst88@gentoo.org> wrote:

> Attempting to merge =x11-proto/kbproto-1.0.6-r1
> results in:
> 
> x11-proto/kbproto:0
> 
>   (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge)
> pulled in by (no parents that aren't satisfied by other packages in
> this slot)
> 
>   (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by
>     x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
> required by (x11-libs/libX11-1.6.2::gentoo, installed)
>     x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
> required by (x11-libs/libXt-1.1.4::gentoo, installed)

No, it doesn't, it gives you a lot more output than that; you appear to
be distracted by something that doesn't appear to be a problem at all.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Thu, 14 Nov 2013 20:56:32 -0800
Matt Turner <mattst88@gentoo.org> wrote:

> Attempting to merge =x11-proto/kbproto-1.0.6-r1
> results in:
> 
> x11-proto/kbproto:0
> 
>   (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge)
> pulled in by (no parents that aren't satisfied by other packages in
> this slot)
> 
>   (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by
>     x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
> required by (x11-libs/libX11-1.6.2::gentoo, installed)
>     x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
> required by (x11-libs/libXt-1.1.4::gentoo, installed)

No, it doesn't, it gives you a lot more output than that; you appear to
be distracted by something that doesn't appear to be a problem at all.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/11/13 02:24 PM, Tom Wijsman wrote:
> On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner
> <mattst88@gentoo.org> wrote:
> 
>> Attempting to merge =x11-proto/kbproto-1.0.6-r1 results in:
>> 
>> x11-proto/kbproto:0
>> 
>> (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) 
>> pulled in by (no parents that aren't satisfied by other packages
>> in this slot)
>> 
>> (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by 
>> x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
>>
>> 
required by (x11-libs/libX11-1.6.2::gentoo, installed)
>> x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
>>
>> 
required by (x11-libs/libXt-1.1.4::gentoo, installed)
> 
> No, it doesn't, it gives you a lot more output than that; you
> appear to be distracted by something that doesn't appear to be a
> problem at all.
> 

Not only that, but these spurious slot collision "errors" pop up all
the time and are useful only for confusing portage users, unless they
actually get it right in the very rare cases -- and they only get it
right, it seems, when you don't see "no parents that aren't satisfied
by other packages in this slot" on one side of the collision.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKGdogACgkQ2ugaI38ACPBlWAD8CxzN2Q2jnkCZkmrXcBpTQNoD
v30A1BnDvJen3JilQf0A/jm3aT/2B7vY7xwqTCnlaRE8VQNjgJQptn3HT7LRCic0
=nEcM
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Matt Turner]

On Fri, Nov 15, 2013 at 11:24 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 14 Nov 2013 20:56:32 -0800
> Matt Turner <mattst88@gentoo.org> wrote:
>
>> Attempting to merge =x11-proto/kbproto-1.0.6-r1
>> results in:
>>
>> x11-proto/kbproto:0
>>
>>   (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge)
>> pulled in by (no parents that aren't satisfied by other packages in
>> this slot)
>>
>>   (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by
>>     x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
>> required by (x11-libs/libX11-1.6.2::gentoo, installed)
>>     x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
>> required by (x11-libs/libXt-1.1.4::gentoo, installed)
>
> No, it doesn't, it gives you a lot more output than that; you appear to
> be distracted by something that doesn't appear to be a problem at all.

What? Where do you get off telling me that the output I copied and
pasted into this email is wrong?

dynamic71 mattst88 # grep kbproto /etc/portage/package.keywords/xorg
=x11-proto/kbproto-1.0.6-r1
dynamic71 mattst88 # emerge '=x11-proto/kbproto-1.0.6-r1' -vp

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

Calculating dependencies... done!
[ebuild   R    ] x11-proto/kbproto-1.0.6-r1  ABI_X86="32 (64) (-x32)" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

dynamic71 mattst88 # sed -i -e
's|=x11-proto/kbproto|#=x11-proto/kbproto|'
/etc/portage/package.keywords/xorg
dynamic71 mattst88 # grep kbproto /etc/portage/package.keywords/xorg
#=x11-proto/kbproto-1.0.6-r1
dynamic71 mattst88 # emerge '=x11-proto/kbproto-1.0.6-r1' -vp

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

Calculating dependencies... done!
[ebuild   R    ] x11-proto/kbproto-1.0.6-r1  ABI_X86="(64) (-32*) (-x32)" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

x11-proto/kbproto:0

  (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by
    x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
required by (x11-libs/libX11-1.6.2::gentoo, installed)
    x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
required by (x11-libs/libXt-1.1.4::gentoo, installed)


!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Thu, 14 Nov 2013 20:56:32 -0800
Matt Turner <mattst88@gentoo.org> wrote:

> There's a single problem. It can't enable abi_x86_32. Why didn't it
> just say that?

As per the full output, it does:

!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.

That together with ABI_X86="(64) (-32*) (-x32)" from the package line
makes it clear that it is trying to change that USE flag. But as you
haven't told emerge yet to do so, it doesn't; which makes it unable.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Peter Stuge]

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

Tom Wijsman wrote:
> !!! Enabling --newuse and --update might solve this conflict.
> !!! If not, it might help emerge to give a more specific suggestion.
> 
> That together with ABI_X86="(64) (-32*) (-x32)" from the package line
> makes it clear that it is trying to change that USE flag.

I disagree quite strongly with that statement. There is no clear
message at all about the situation.

The problem is that the USE flag is "hidden" on the package line as
opposed to mentioned explicitly by portage. It's easy for software to
print meaningful output based on the data it has while it is awkward
for humans to scan lines and lines of output for parentheses with *s
and -s.


I very much appreciate that you clarified what you meant by "No".


Thanks

//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Ian Stakenvicius <axs@gentoo.org> wrote:
> On 15/11/13 10:54 AM, Peter Stuge wrote:
>> ..
>>> I think most of the confusion is caused by the necessity to put
>>> a *stable* package atom into package.keywords to unmask a *USE*
>>> flag.
>>
>> A lot can be learned just from the filenames:
>> [...]
>> The latter indicates that this concept has no less than four
>> dimensions.
>
> Well, reordering this a bit: [...]
> So I don't think this is entirely unclear.

I think the point of Peter is not whether the *name* of the
file is optimally chosen: His point is that the *semantics*
(which is somehow reflected in the name) is too complex in
the sense that it combines at least two concepts
(USE-Flags and Stability) which from th
user's point of view are completely unrelated.

Only the developer's point of view of wanting to stabilize
something earlier makes a connection between these concepts,
but it is not really a natural conncetion:
For someone who is not familiar with implicit implications
of every USE-flag (i.e. a non-developer), the result looks
like an almost random change of active USE-flags.

Probably a lot of the confusion could be avoided if
/etc/portage/package.accept_keywords would not implicitly
unmask useflags.

If this is not very hard to implement in portage, I would
strongly vote to remove this implicit connection:
This side effect is obviously the cause of the
"dependency hell" examples.

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Peter Stuge]

Martin Vaeth wrote:
> Probably a lot of the confusion could be avoided if
> /etc/portage/package.accept_keywords would not implicitly
> unmask useflags.

I think so too.

Anything that happens implicitly where explicit knobs exist is really
counter-intuitive.


//Peter

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Fri, 15 Nov 2013 21:10:41 +0100
Peter Stuge <peter@stuge.se> wrote:

> Tom Wijsman wrote:
> > !!! Enabling --newuse and --update might solve this conflict.
> > !!! If not, it might help emerge to give a more specific suggestion.
> > 
> > That together with ABI_X86="(64) (-32*) (-x32)" from the package
> > line makes it clear that it is trying to change that USE flag.
> 
> I disagree quite strongly with that statement. There is no clear
> message at all about the situation.
>
> The problem is that the USE flag is "hidden" on the package line as
> opposed to mentioned explicitly by portage. It's easy for software to
> print meaningful output based on the data it has while it is awkward
> for humans to scan lines and lines of output for parentheses with *s
> and -s.

Which is not the case here; as a single package is being emerged, the
output is rather short. So, it is as clear as how much you read of it.

The shortness of the output actually makes it much easier to scan.

The other case would be `emerge -uDN @world` which gives a lot of
output; but that case is different, as it wouldn't suggest the above.

Now imaging if that long output was very much longer; the longness of
that output, would be quite impossible to scan within the time one
would process the normal `emerge -uDN @world` output.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Matt Turner]

On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 14 Nov 2013 20:56:32 -0800
> Matt Turner <mattst88@gentoo.org> wrote:
>
>> There's a single problem. It can't enable abi_x86_32. Why didn't it
>> just say that?
>
> As per the full output, it does:
>
> !!! Enabling --newuse and --update might solve this conflict.
> !!! If not, it might help emerge to give a more specific suggestion.
>
> That together with ABI_X86="(64) (-32*) (-x32)" from the package line
> makes it clear that it is trying to change that USE flag. But as you
> haven't told emerge yet to do so, it doesn't; which makes it unable.

Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked),
unmerge kbproto and attempt to emerge libXt:

dynamic71 mattst88 # emerge libXt -vp

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

Calculating dependencies... done!

emerge: there are no ebuilds built with USE flags to satisfy
"x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
!!! One of the following packages is required to complete your request:
- x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
(dependency required by "x11-libs/libXt-1.1.4" [ebuild])
(dependency required by "libXt" [argument])

It suggests that I turn off abi_x86_32 for libXt rather than telling
me to turn the flag on for kbproto!

Portage prints other things intelligently:

mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp

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

Calculating dependencies... done!


[nomerge       ] dev-python/py-1.4.13  USE="{test}"
PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)"
[ebuild  N     ]  dev-python/pytest-2.3.5  USE="{test} -doc"
PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)" 417 kB
[ebuild  N     ]   dev-python/py-1.4.13  USE="{test}"
PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)" 185 kB

Total: 2 packages (2 new), Size of downloads: 602 kB

 * Error: circular dependencies:

(dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on
 (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge) (buildtime)
  (dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) (buildtime)

It might be possible to break this cycle
by applying the following change:
- dev-python/py-1.4.13 (Change USE: -test)

Note that this change can be reverted, once the package has been installed.

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Fri, 15 Nov 2013 12:25:47 -0800
Matt Turner <mattst88@gentoo.org> wrote:

> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
> kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
> libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked),
> unmerge kbproto and attempt to emerge libXt:
> 
> [...]
> 
> emerge: there are no ebuilds built with USE flags to satisfy
> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
> !!! One of the following packages is required to complete your
> request:
> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
> (dependency required by "x11-libs/libXt-1.1.4" [ebuild])
> (dependency required by "libXt" [argument])
> 
> It suggests that I turn off abi_x86_32 for libXt rather than telling
> me to turn the flag on for kbproto!

Why should it literally suggest you to do something known to be broken?

It is clear from the output how it wants the dependency to be; so, if
you want to do something different, you can and the output tells enough.

Due to the complexity of the dependency, you will need `man 5 ebuild`
though; (-) means to assume it as disabled if it doesn't exist.

> Portage prints other things intelligently:
> 
> mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> 
> [nomerge       ] dev-python/py-1.4.13  USE="{test}"
> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> (-python3_3)"
> [ebuild  N     ]  dev-python/pytest-2.3.5  USE="{test} -doc"
> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> (-python3_3)" 417 kB
> [ebuild  N     ]   dev-python/py-1.4.13  USE="{test}"
> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> (-python3_3)" 185 kB
> 
> Total: 2 packages (2 new), Size of downloads: 602 kB
> 
>  * Error: circular dependencies:
> 
> (dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on
>  (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
> (buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
> merge) (buildtime)
> 
> It might be possible to break this cycle
> by applying the following change:
> - dev-python/py-1.4.13 (Change USE: -test)
> 
> Note that this change can be reverted, once the package has been
> installed.

This is just like how you can't compile gcc without having compiled gcc
with another compiler first (or used a binpkg, or obtained from stage3);
thus, similarly, you can't test py without having pytest first etc...

For example, emerging dev-java/icedtea without a Java compiler / runtime
present will show you the same behavior; and there are some other
circular dependencies present in the tree that behave similarly.

It's a problem that you can't really solve as far as I know; bugs are
often getting filed for it, but without a fix. One filed against
Portage is for example https://bugs.gentoo.org/show_bug.cgi?id=417675
but it hasn't received much attention; because well, I doubt if a proper
solution to this would be simple.

Workarounds mentioned are hacking up the vdb or changing --newuse.

Does replacing this "explicit behavior" by "implicit behavior" make
sense for the users in general? Does it make sense for those that just
want to test? Will people understand it if it were implicit behavior?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Peter Stuge]

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

Tom Wijsman wrote:
> Does replacing this "explicit behavior" by "implicit behavior" make
> sense for the users in general?

Please don't warp the words. Maybe I misunderstand, but it seems like
that's what you're doing.

I'll try to clarify:

With explicit I was refering to allowing manual setting and unsetting
of USE flags, keywords and masks.

With implicit I was refering to those same things happening automatically.
USE flags set or unset automatically, keywords set or unset automatically,
masks set or unset automatically - as a result of something or other.

Any such automations significantly diminish the value of the explicit knobs
and are counter-intuitive.

If someone is given a mechanism to control which USE flags are set or
unset then it's just stupid to go "around" those settings.


I understand the temptation to make things happen automatically for ease
of development, and that is perfectly fine as long as those automations
aren't exposed to users.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Matt Turner]

On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Fri, 15 Nov 2013 12:25:47 -0800
> Matt Turner <mattst88@gentoo.org> wrote:
>
>> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman <TomWij@gentoo.org>
>> wrote:
>> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
>> kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
>> libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked),
>> unmerge kbproto and attempt to emerge libXt:
>>
>> [...]
>>
>> emerge: there are no ebuilds built with USE flags to satisfy
>> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
>> !!! One of the following packages is required to complete your
>> request:
>> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
>> (dependency required by "x11-libs/libXt-1.1.4" [ebuild])
>> (dependency required by "libXt" [argument])
>>
>> It suggests that I turn off abi_x86_32 for libXt rather than telling
>> me to turn the flag on for kbproto!
>
> Why should it literally suggest you to do something known to be broken?

I don't know what you mean. kbproto[abi_x86_32] isn't known to be
broken. You're asking a really weird question based on some implicit
context that's not available to me.

I'm claiming in this example that attempting to emerge
libXt[abi_x86_32], portage should tell you that abi_x86_32 should be
set for kbproto, rather than telling you to unset abi_x86_32 for libXt
(which you're requesting to be emerged, damn it!).

> It is clear from the output how it wants the dependency to be; so, if
> you want to do something different, you can and the output tells enough.
>
> Due to the complexity of the dependency, you will need `man 5 ebuild`
> though; (-) means to assume it as disabled if it doesn't exist.
>
>> Portage prints other things intelligently:
>>
>> mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>>
>> [nomerge       ] dev-python/py-1.4.13  USE="{test}"
>> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
>> (-python3_3)"
>> [ebuild  N     ]  dev-python/pytest-2.3.5  USE="{test} -doc"
>> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
>> (-python3_3)" 417 kB
>> [ebuild  N     ]   dev-python/py-1.4.13  USE="{test}"
>> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
>> (-python3_3)" 185 kB
>>
>> Total: 2 packages (2 new), Size of downloads: 602 kB
>>
>>  * Error: circular dependencies:
>>
>> (dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on
>>  (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
>> (buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
>> merge) (buildtime)
>>
>> It might be possible to break this cycle
>> by applying the following change:
>> - dev-python/py-1.4.13 (Change USE: -test)
>>
>> Note that this change can be reverted, once the package has been
>> installed.
>
> This is just like how you can't compile gcc without having compiled gcc
> with another compiler first (or used a binpkg, or obtained from stage3);
> thus, similarly, you can't test py without having pytest first etc...

I don't think you understood my intention for giving this example.
Portage correctly figures out the proper solution and suggests it. I'm
saying that this is a good thing.

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Fri, 15 Nov 2013 22:09:04 +0100
Peter Stuge <peter@stuge.se> wrote:

> Tom Wijsman wrote:
> > Does replacing this "explicit behavior" by "implicit behavior" make
> > sense for the users in general?
> 
> Please don't warp the words. Maybe I misunderstand, but it seems like
> that's what you're doing.
> 
> I'll try to clarify:
> 
> With explicit I was refering to allowing manual setting and unsetting
> of USE flags, keywords and masks.
> 
> With implicit I was refering to those same things happening
> automatically. USE flags set or unset automatically, keywords set or
> unset automatically, masks set or unset automatically - as a result
> of something or other.
> 
> Any such automations significantly diminish the value of the explicit
> knobs and are counter-intuitive.

"implicit" in the context of this sub thread is it being present as
part of another choice, whereas "explicit" makes it a separate choice.
Currently the behavior is explicit because you have to break the
dependency cycle yourself and decide how to, whereas making it implicit
would solve it; in one or another particular way you'd be unaware of.

> If someone is given a mechanism to control which USE flags are set or
> unset then it's just stupid to go "around" those settings.

This example was about a circular dependency, not about USE flags.

> I understand the temptation to make things happen automatically for
> ease of development, and that is perfectly fine as long as those
> automations aren't exposed to users.

And that's the question, it is the hard part of figuring it out... :)

(To be clear: In the context of the sub thread answering the example.)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Fri, 15 Nov 2013 13:21:53 -0800
Matt Turner <mattst88@gentoo.org> wrote:

> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> > On Fri, 15 Nov 2013 12:25:47 -0800
> > Matt Turner <mattst88@gentoo.org> wrote:
> >
> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman <TomWij@gentoo.org>
> >> wrote:
> >> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag
> >> for kbproto but was attempting to emerge unstable (or unmasked
> >> abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that
> >> abi_x86_32 is masked), unmerge kbproto and attempt to emerge libXt:
> >>
> >> [...]
> >>
> >> emerge: there are no ebuilds built with USE flags to satisfy
> >> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
> >> !!! One of the following packages is required to complete your
> >> request:
> >> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
> >> (dependency required by "x11-libs/libXt-1.1.4" [ebuild])
> >> (dependency required by "libXt" [argument])
> >>
> >> It suggests that I turn off abi_x86_32 for libXt rather than
> >> telling me to turn the flag on for kbproto!
> >
> > Why should it literally suggest you to do something known to be
> > broken?
> 
> I don't know what you mean. kbproto[abi_x86_32] isn't known to be
> broken. You're asking a really weird question based on some implicit
> context that's not available to me.

A mask implies something is broken (or experimental).

> I'm claiming in this example that attempting to emerge
> libXt[abi_x86_32], portage should tell you that abi_x86_32 should be
> set for kbproto, rather than telling you to unset abi_x86_32 for libXt
> (which you're requesting to be emerged, damn it!).

You have to be explicit when you want broken (or experimental) things;
just emerging it isn't enough, taking a step further than that is.

I'm not sure if making broken (or experimental) things more easily
available or a suggestion would be a good idea; people already have
enough trouble as it is, adding more doesn't seem to be the right way.

> > It is clear from the output how it wants the dependency to be; so,
> > if you want to do something different, you can and the output tells
> > enough.
> >
> > Due to the complexity of the dependency, you will need `man 5
> > ebuild` though; (-) means to assume it as disabled if it doesn't
> > exist.
> >
> >> Portage prints other things intelligently:
> >>
> >> mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
> >>
> >> These are the packages that would be merged, in order:
> >>
> >> Calculating dependencies... done!
> >>
> >>
> >> [nomerge       ] dev-python/py-1.4.13  USE="{test}"
> >> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> >> (-python3_3)"
> >> [ebuild  N     ]  dev-python/pytest-2.3.5  USE="{test} -doc"
> >> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> >> (-python3_3)" 417 kB
> >> [ebuild  N     ]   dev-python/py-1.4.13  USE="{test}"
> >> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> >> (-python3_3)" 185 kB
> >>
> >> Total: 2 packages (2 new), Size of downloads: 602 kB
> >>
> >>  * Error: circular dependencies:
> >>
> >> (dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends
> >> on (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
> >> (buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
> >> merge) (buildtime)
> >>
> >> It might be possible to break this cycle
> >> by applying the following change:
> >> - dev-python/py-1.4.13 (Change USE: -test)
> >>
> >> Note that this change can be reverted, once the package has been
> >> installed.
> >
> > This is just like how you can't compile gcc without having compiled
> > gcc with another compiler first (or used a binpkg, or obtained from
> > stage3); thus, similarly, you can't test py without having pytest
> > first etc...
> 
> I don't think you understood my intention for giving this example.
> Portage correctly figures out the proper solution and suggests it. I'm
> saying that this is a good thing.

Now the question is whether this is or isn't an opposite example;
because it might very well be intelligent, that doesn't mean that the
other example isn't intelligent. As we trying to make that clear, this
example doesn't really fit; so, I didn't assume it to be opposite.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Matt Turner]

On Fri, Nov 15, 2013 at 1:38 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Fri, 15 Nov 2013 13:21:53 -0800
> Matt Turner <mattst88@gentoo.org> wrote:
>
>> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman <TomWij@gentoo.org>
>> wrote:
>> > On Fri, 15 Nov 2013 12:25:47 -0800
>> > Matt Turner <mattst88@gentoo.org> wrote:
>> >
>> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman <TomWij@gentoo.org>
>> >> wrote:
>> >> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag
>> >> for kbproto but was attempting to emerge unstable (or unmasked
>> >> abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that
>> >> abi_x86_32 is masked), unmerge kbproto and attempt to emerge libXt:
>> >>
>> >> [...]
>> >>
>> >> emerge: there are no ebuilds built with USE flags to satisfy
>> >> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
>> >> !!! One of the following packages is required to complete your
>> >> request:
>> >> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
>> >> (dependency required by "x11-libs/libXt-1.1.4" [ebuild])
>> >> (dependency required by "libXt" [argument])
>> >>
>> >> It suggests that I turn off abi_x86_32 for libXt rather than
>> >> telling me to turn the flag on for kbproto!
>> >
>> > Why should it literally suggest you to do something known to be
>> > broken?
>>
>> I don't know what you mean. kbproto[abi_x86_32] isn't known to be
>> broken. You're asking a really weird question based on some implicit
>> context that's not available to me.
>
> A mask implies something is broken (or experimental).

Then to answer your previous question: it would suggest it [something
broken, according to you] because you've asked for something broken
that depends on it!

>> I'm claiming in this example that attempting to emerge
>> libXt[abi_x86_32], portage should tell you that abi_x86_32 should be
>> set for kbproto, rather than telling you to unset abi_x86_32 for libXt
>> (which you're requesting to be emerged, damn it!).
>
> You have to be explicit when you want broken (or experimental) things;
> just emerging it isn't enough, taking a step further than that is.

I'm explicitly saying that I want libXt with USE=abi_x86_32.
Suggesting that I turn it off is kind of ridiculous, don't you think?

This seems pretty clear cut. Are you just jerking me around now?

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Peter Stuge]

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

Tom Wijsman wrote:
> I'm not sure if making broken (or experimental) things more easily
> available or a suggestion would be a good idea; people already have
> enough trouble as it is, adding more doesn't seem to be the right way.

It's not about broken/experimental, it's about the logical
consequences of an explicit action taken by the user.

The user must get feedback based on what they said that they wanted
to do, not based on what is experimental.

Mentioning that something is experimental is an optional bonus, but
assuming that the user already knows that this is the case is OK too.


portage should say, with as similar wording as possible:

"If you want to emerge libXt with those USE flags then you'll also
have to set those same USE flags for libYt and libZt because libXt
DEPENDs on them."


Bonus points:

"Would you like me to set those USE flags for libYt and libZt for
you? [Y/n]"


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Fri, 15 Nov 2013 13:45:29 -0800
Matt Turner <mattst88@gentoo.org> wrote:

> On Fri, Nov 15, 2013 at 1:38 PM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> > On Fri, 15 Nov 2013 13:21:53 -0800
> > Matt Turner <mattst88@gentoo.org> wrote:
> >
> >> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman <TomWij@gentoo.org>
> >> wrote:
> >> > On Fri, 15 Nov 2013 12:25:47 -0800
> >> > Matt Turner <mattst88@gentoo.org> wrote:
> >> >
> >> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman
> >> >> <TomWij@gentoo.org> wrote:
> >> >> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag
> >> >> for kbproto but was attempting to emerge unstable (or unmasked
> >> >> abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that
> >> >> abi_x86_32 is masked), unmerge kbproto and attempt to emerge
> >> >> libXt:
> >> >>
> >> >> [...]
> >> >>
> >> >> emerge: there are no ebuilds built with USE flags to satisfy
> >> >> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
> >> >> !!! One of the following packages is required to complete your
> >> >> request:
> >> >> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
> >> >> (dependency required by "x11-libs/libXt-1.1.4" [ebuild])
> >> >> (dependency required by "libXt" [argument])
> >> >>
> >> >> It suggests that I turn off abi_x86_32 for libXt rather than
> >> >> telling me to turn the flag on for kbproto!
> >> >
> >> > Why should it literally suggest you to do something known to be
> >> > broken?
> >>
> >> I don't know what you mean. kbproto[abi_x86_32] isn't known to be
> >> broken. You're asking a really weird question based on some
> >> implicit context that's not available to me.
> >
> > A mask implies something is broken (or experimental).
> 
> Then to answer your previous question: it would suggest it [something
> broken, according to you] because you've asked for something broken
> that depends on it!

Because a maintainer or achitecture team forgot to cover that case and
didn't check on reverse dependencies, which is another case; but even
in this case Portage handles well, as it suggests to step away from the
brokenness.

> >> I'm claiming in this example that attempting to emerge
> >> libXt[abi_x86_32], portage should tell you that abi_x86_32 should
> >> be set for kbproto, rather than telling you to unset abi_x86_32
> >> for libXt (which you're requesting to be emerged, damn it!).
> >
> > You have to be explicit when you want broken (or experimental)
> > things; just emerging it isn't enough, taking a step further than
> > that is.
> 
> I'm explicitly saying that I want libXt with USE=abi_x86_32.
> Suggesting that I turn it off is kind of ridiculous, don't you think?

In your case, yes. In general, no; if you suggest to do this to anyone
instead of just the small few that want it, it would encourage people
to override what we mark as broken and that is a recipe for disaster.

> This seems pretty clear cut. Are you just jerking me around now?

For your case it could be made better, but as this very same output
gets the eyes of people with other intentions; we can't just outright
apply it that way and break systems, we have to satisfy most parties.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Fri, 15 Nov 2013 22:57:06 +0100
Peter Stuge <peter@stuge.se> wrote:

> Tom Wijsman wrote:
> > I'm not sure if making broken (or experimental) things more easily
> > available or a suggestion would be a good idea; people already have
> > enough trouble as it is, adding more doesn't seem to be the right
> > way.
> 
> It's not about broken/experimental, it's about the logical
> consequences of an explicit action taken by the user.
> 
> The user must get feedback based on what they said that they wanted
> to do, not based on what is experimental.
> 
> Mentioning that something is experimental is an optional bonus, but
> assuming that the user already knows that this is the case is OK too.

The * in the USE flag list marks this.

> portage should say, with as similar wording as possible:
> 
> "If you want to emerge libXt with those USE flags then you'll also
> have to set those same USE flags for libYt and libZt because libXt
> DEPENDs on them."
> 
> Bonus points:
> 
> "Would you like me to set those USE flags for libYt and libZt for
> you? [Y/n]"

Which part of this warns the user that the user is about to run into
something broken / experimental? We need to add that too, because it is
not clear from the output that you suggest. And if we add that as well,
it gets to be quite long; how would we condense that?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Peter Stuge]

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

Tom Wijsman wrote:
> > portage should say, with as similar wording as possible:
> > 
> > "If you want to emerge libXt with those USE flags then you'll also
> > have to set those same USE flags for libYt and libZt because libXt
> > DEPENDs on them."
> > 
> > Bonus points:
> > 
> > "Would you like me to set those USE flags for libYt and libZt for
> > you? [Y/n]"
> 
> Which part of this warns the user that the user is about to run into
> something broken / experimental? We need to add that too, because it is
> not clear from the output that you suggest. And if we add that as well,
> it gets to be quite long;

It gets one word longer:

"If you want to emerge libXt with those experimental USE flags then
you'll also have to set those same USE flags for libYt and libZt
because libXt DEPENDs on them."


> how would we condense that?

If something is a bit complicated then a bit more verbosity can be
really good.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-15, o godz. 14:53:00
Ben de Groot <yngwin@gentoo.org> napisał(a):

> As I see it now, with respect to multilib, we have three competing
> solutions, but not a clear direction which way we want to go as a
> distro:
> 
> 1: emul-* packages
> 2: multilib-portage
> 3: multilib.eclass
> 
> I would like to vote for option 1, as it is the least intrusive and
> does what we need. If it is really felt we need a more complete
> solution, then my vote would be for 2, since 3 is too intrusive and
> more likely to break or complicate stuff for normal users.
> 
> If you say council should take more of a leadership role, then maybe
> this issue can be decided by council and a clear direction be taken by
> the distro as a whole? Then those who oppose the choice made can
> either put up or shut up, and we can all work at implementing the
> chosen solution.

And what does, say, a Council decision change? Sure, Council can affect
opinions of some developers and so on but this is something that needs
real work, not talking and deciding. Sure, you can convince
the developers that X is better than Y but you also need to find
someone who will actually work on X.

And I think the actual work done by *different* people shows which
solution is most preferred by the community. This is not something that
judges whether it's the best one, but probably it'll the most
maintainable one. Think of bus factor.

About your list, let's first note that emul-linux are not dead. We're
working on getting a replacement but we aren't dumping them yet
and we're actively encouraging developers to use any-of deps to support
both multilib packages and emul-linux. As you probably have seen,
emul-linux even had an update recently.

On the other hand, let's be honest -- emul-linux are basically
single-handedly maintained by Pacho. I can't talk for him but if you
really want to keep that supported long-term, you need to find people
who are going to work on them actively.

I don't know the exact number of people actively working
on multilib-portage but I haven't seen any progress on getting all
the formal stuff done. And remember that this particular idea requires
much more work since it assumes the spec becoming part of immutable
EAPI -- getting it all right, extensive testing, considering all the
corner cases, etc.

One thing I can tell is that gx86-multilib is getting the widest
support of all the solutions. It has most active developers, most
active helping users and some support from random developers that just
maintain their packages. It requires less work on the formal side,
and gets better testing for the simple reason that you need to do it
per-package.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Fri, 15 Nov 2013 23:26:57 +0100
Peter Stuge <peter@stuge.se> wrote:

> Tom Wijsman wrote:
> > > portage should say, with as similar wording as possible:
> > > 
> > > "If you want to emerge libXt with those USE flags then you'll also
> > > have to set those same USE flags for libYt and libZt because libXt
> > > DEPENDs on them."
> > > 
> > > Bonus points:
> > > 
> > > "Would you like me to set those USE flags for libYt and libZt for
> > > you? [Y/n]"
> > 
> > Which part of this warns the user that the user is about to run into
> > something broken / experimental? We need to add that too, because
> > it is not clear from the output that you suggest. And if we add
> > that as well, it gets to be quite long;
> 
> It gets one word longer:
> 
> "If you want to emerge libXt with those experimental USE flags then
> you'll also have to set those same USE flags for libYt and libZt
> because libXt DEPENDs on them."

By making it a single word its true meaning is hidden; broken or
experimental are just two possible meanings, there are others (eg.
security masks). I think we will want to be more explicit here.

> > how would we condense that?
> 
> If something is a bit complicated then a bit more verbosity can be
> really good.

Extra words and verbosity's relationship depends on which extra words
and what verbosity that one aims to achieve; so, it might be possible
to condense this without making a change in verbosity, or even add
verbosity by reaching more with less output (in processable list form):

    emerge: there are no ebuilds built with USE flags to satisfy
    "x11-proto/kbproto[abi_x86_32]".
    (dependency required by "x11-libs/libXt-1.1.4" [ebuild])
    (dependency required by "libXt" [argument])
    because of default/linux/amd64/13.0/package.use.stable.mask:1:

        # Ian Stakenvicius <axs@gentoo.org> (20 Sep 2013)
        # on behalf of gx86-multilib project <multilib@gentoo.org>
        # Mask abi_x86_32 on stable until emul-* packages are made
        # fully redundant and end-user experience in resolving
        # flag changes and blockages is generally smooth.
        # Please keep in sync with hardened/linux/amd64.
        x11-proto/kbproto abi_x86_32

    Unmask at your own risk or set x11-libs/libXt[-abi_x86_32].

This is similar to the package.mask output.

(Automatic config writing behavior would indeed be nice to have.)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Fri, 15 Nov 2013 23:39:34 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2013-11-15, o godz. 14:53:00
> Ben de Groot <yngwin@gentoo.org> napisał(a):
> 
> > As I see it now, with respect to multilib, we have three competing
> > solutions, but not a clear direction which way we want to go as a
> > distro:
> > 
> > 1: emul-* packages
> > 2: multilib-portage
> > 3: multilib.eclass
> > 
> > I would like to vote for option 1, as it is the least intrusive and
> > does what we need. If it is really felt we need a more complete
> > solution, then my vote would be for 2, since 3 is too intrusive and
> > more likely to break or complicate stuff for normal users.
> > 
> > If you say council should take more of a leadership role, then maybe
> > this issue can be decided by council and a clear direction be taken
> > by the distro as a whole? Then those who oppose the choice made can
> > either put up or shut up, and we can all work at implementing the
> > chosen solution.
> 
> And what does, say, a Council decision change? Sure, Council can
> affect opinions of some developers and so on but this is something
> that needs real work, not talking and deciding. Sure, you can convince
> the developers that X is better than Y but you also need to find
> someone who will actually work on X.
> 
> And I think the actual work done by *different* people shows which
> solution is most preferred by the community. This is not something
> that judges whether it's the best one, but probably it'll the most
> maintainable one. Think of bus factor.

This is comparable to survival of the fittest; you can't just pick an
animal and have it be a success in a circus, you'd need to careful to
see which animal is fit for it and learn it all the tricks. Only then
people will come, watch and come back later...

(Cirque du Soleil thinks outside of the box and doesn't use animals)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Pacho Ramos]

El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió:
> Dnia 2013-11-15, o godz. 14:53:00
> Ben de Groot <yngwin@gentoo.org> napisał(a):
> 
> > As I see it now, with respect to multilib, we have three competing
> > solutions, but not a clear direction which way we want to go as a
> > distro:
> > 
> > 1: emul-* packages

This is the current option but has important drawbacks:
- Each emul set contains a ton of packages, then, when a security issue
arises in one of them, we need to release a new emul-linux-x86-...
- It's built from stable tree, it can then cause inconsistencies when
people run native lib from testing (I remember pulseaudio case)
- If we would like to really follow stabilized packages, we would nearly
need to generate a new set every week because likely some of the
contained packages will be stabilized on x86 so often.
- As they are a big set of packages, people need to install a lot of
stuff they don't really need

In summary -> they are completely unflexible, with the problems it cause

> > 2: multilib-portage

I think this has been discussed multiple times, if I don't misremember,
PMS team is not willing to accept it until the specification is done...
and we are waiting for that for years probably because it includes a lot
of changes (well, Tommy will know much more about this)

> > 3: multilib.eclass
> > 

This is my preferred solution 

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Thomas Sachau]

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

Pacho Ramos schrieb:
> El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió:
>> Dnia 2013-11-15, o godz. 14:53:00
>> Ben de Groot <yngwin@gentoo.org> napisał(a):
>>
>>> As I see it now, with respect to multilib, we have three competing
>>> solutions, but not a clear direction which way we want to go as a
>>> distro:
>>>
>>> 1: emul-* packages
> 
> This is the current option but has important drawbacks:
> - Each emul set contains a ton of packages, then, when a security issue
> arises in one of them, we need to release a new emul-linux-x86-...
> - It's built from stable tree, it can then cause inconsistencies when
> people run native lib from testing (I remember pulseaudio case)
> - If we would like to really follow stabilized packages, we would nearly
> need to generate a new set every week because likely some of the
> contained packages will be stabilized on x86 so often.
> - As they are a big set of packages, people need to install a lot of
> stuff they don't really need
> 
> In summary -> they are completely unflexible, with the problems it cause
> 
>>> 2: multilib-portage
> 
> I think this has been discussed multiple times, if I don't misremember,
> PMS team is not willing to accept it until the specification is done...
> and we are waiting for that for years probably because it includes a lot
> of changes (well, Tommy will know much more about this)

Ever tried to write a formal spec in a foreing language? Creating
multilib-portage was easier then this request....

Anyway, the new multilib eclasses had no entrance barrier, so have been
added and effectively everyone is forced to use them.

Since i dont expect anyone to vote for a different solution in the
future, which would force all multilib related parts to be rewritten, i
stopped my work on the spec part.
If anyone wants to continue that road, i can hand over any pieces i
already have.

Instead i will simply prepare/maintain multilib-portage as a
portage-only package manager based multilib solution, which requires no
changes to ebuilds. This also keeps a choice for users, who cant or dont
want to convert all needed ebuilds to the new multilib eclasses.


-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Pacho Ramos <pacho@gentoo.org> wrote:
>
>> > 3: multilib.eclass
>> >
>
> This is my preferred solution

However, it has some serious drawbacks; most importantly:
It implies that the same USE-flags must be used for the
native and 32-bit variant.

This is really a severe restriction since the motivation
for installation can be very different for these variants.
For instance, for a native ffmpeg the user might want support
for a lot of codecs/devices while for the 32 bit variant
the user might want only support for those codecs/devices
which are needed for some special application. Nevertheless,
the same useflags mean that he has to build the same
(with all implied dependencies) also for 32 bit.

Currently, this particular example is not so bad, since
currently de facto ffmpeg:0.10 is the 32 bit version while
ffmpeg:0 is the native version, and so the useflags can differ.
However, it seems more like an accident that this does not occur
here, in the moment.

A "cleaner" solution would somehow treat the 32bit and
64bit variant like separate packages, each having its
own set of USE-Flags, and also the possibility to rebuild
one without rebuilding the other. AFAIK multilib-portage
can do this.

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 429 bytes --]

Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:

> If this is not very hard to implement in portage, I would
> strongly vote to remove this implicit connection:

Not really doable since this is explicitly defined as such in EAPI=5 PMS.

Retroactively changing PMS is probably not a good idea.

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-16, o godz. 12:39:37
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> napisał(a):

> Pacho Ramos <pacho@gentoo.org> wrote:
> >
> >> > 3: multilib.eclass
> >> >
> >
> > This is my preferred solution
> 
> However, it has some serious drawbacks; most importantly:
> It implies that the same USE-flags must be used for the
> native and 32-bit variant.

We are aware of that. However, there were no solution proposed that
wouldn't make the things horribly complex.

> A "cleaner" solution would somehow treat the 32bit and
> 64bit variant like separate packages, each having its
> own set of USE-Flags, and also the possibility to rebuild
> one without rebuilding the other. AFAIK multilib-portage
> can do this.

Really? Last time I checked it didn't have that option. Unless you mean
theoretically...

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 650 bytes --]

Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:

> Probably a lot of the confusion could be avoided if
> /etc/portage/package.accept_keywords would not implicitly
> unmask useflags.

How would you handle the case if a package has only one version in portage and 
that one is stable? 

Just completely disable the features provided by stable.masked useflags?

Force the existence of a revbump with an extra rebuild, just so there's an 
unstable version around?

Believe me, we've been thinking about this...

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-16, o godz. 13:50:11
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
> 
> > Probably a lot of the confusion could be avoided if
> > /etc/portage/package.accept_keywords would not implicitly
> > unmask useflags.
> 
> How would you handle the case if a package has only one version in portage and 
> that one is stable? 

Unmask it through use.stable.mask and package.use.stable.mask
in /etc/portage/profile?

Then we clear separation between masked packages and masked flags.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Kent Fredric]

On 17 November 2013 01:39, Martin Vaeth
<vaeth@mathematik.uni-wuerzburg.de> wrote:
>
> This is really a severe restriction since the motivation
> for installation can be very different for these variants.
> For instance, for a native ffmpeg the user might want support
> for a lot of codecs/devices while for the 32 bit variant
> the user might want only support for those codecs/devices
> which are needed for some special application. Nevertheless,
> the same useflags mean that he has to build the same
> (with all implied dependencies) also for 32 bit.


Imo, thats a really good point. The convenience of having 1 ebuild
support both 64bit and 32bit is sort of like a conflation of classes,
because it behaves similar to having 2 ebuilds dove-tailed into one.

Being able to specify different dependencies for different arches
seems something that would be useful, especially in the following
cases:

Imagine, an ebuild provides 32bit and 64bit implementations.

User only needs USE="a b c" for the 64bit version, but only USE="a"
for the 32bit version.

"c" however, on 32bit, needs a dependency to make it work on 32bit to
smooth over a difference.
But that dependency is unneeded on the 64bit version.

Which means that USE="arch_32 arch_64 a b c" pulls in more
dependencies than necessary to satisfy the users systems requirements.

Just the overhead work to debride it and have a seperate package, or a
seperate slot per ARCH_ABI might be more problem than its worth.

So its just a question here of which tradeoffs are more acceptable for
most of our audience.

( Yes, I'm referring to a similar question that came up the other day
as to the advantages of having <gvim> independent from <vim> and
<vim-core>, and being able to have different USE flags for each was
seen as a distinct advantage of the separation )

-- 
Kent

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-17, o godz. 09:24:26
Kent Fredric <kentfredric@gmail.com> napisał(a):

> On 17 November 2013 01:39, Martin Vaeth
> <vaeth@mathematik.uni-wuerzburg.de> wrote:
> >
> > This is really a severe restriction since the motivation
> > for installation can be very different for these variants.
> > For instance, for a native ffmpeg the user might want support
> > for a lot of codecs/devices while for the 32 bit variant
> > the user might want only support for those codecs/devices
> > which are needed for some special application. Nevertheless,
> > the same useflags mean that he has to build the same
> > (with all implied dependencies) also for 32 bit.
> 
> 
> Imo, thats a really good point. The convenience of having 1 ebuild
> support both 64bit and 32bit is sort of like a conflation of classes,
> because it behaves similar to having 2 ebuilds dove-tailed into one.
> 
> Being able to specify different dependencies for different arches
> seems something that would be useful, especially in the following
> cases:
> 
> Imagine, an ebuild provides 32bit and 64bit implementations.
> 
> User only needs USE="a b c" for the 64bit version, but only USE="a"
> for the 32bit version.
> 
> "c" however, on 32bit, needs a dependency to make it work on 32bit to
> smooth over a difference.
> But that dependency is unneeded on the 64bit version.
> 
> Which means that USE="arch_32 arch_64 a b c" pulls in more
> dependencies than necessary to satisfy the users systems requirements.

Unless I'm misunderstanding something, you are not correct.

You can surely do something like:

  RDEPEND="abi_x86_32? ( dev-libs/c[abi_x86_32(-)] )"

(and a matching multilib_src_configure)

> Just the overhead work to debride it and have a seperate package, or a
> seperate slot per ARCH_ABI might be more problem than its worth.
> 
> So its just a question here of which tradeoffs are more acceptable for
> most of our audience.

You mean having N forks where N is the number of ABIs (3 for x86 + 3
for mips currently). You will need to mask some (or all) of them for
other arches, and so on. Then we may want to add support for another
multilib arch/ABI...

-- 
Best regards,
Michał Górny

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

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Duncan]

Martin Vaeth posted on Sat, 16 Nov 2013 12:39:37 +0000 as excerpted:

> A "cleaner" solution would somehow treat the 32bit and 64bit variant
> like separate packages, each having its own set of USE-Flags, and also
> the possibility to rebuild one without rebuilding the other. AFAIK
> multilib-portage can do this.

I'm not sure about multlib-portage, but the chroot option certainly 
treats them as separate packages, each with its own config, because 
that's exactly what they are, there! =:^)

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

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Kent Fredric]

On 17 November 2013 10:52, Michał Górny <mgorny@gentoo.org> wrote:
> Unless I'm misunderstanding something, you are not correct.
>
> You can surely do something like:
>
>   RDEPEND="abi_x86_32? ( dev-libs/c[abi_x86_32(-)] )"


It was more you cant do

IUSE="foo"

without doing

RDEPEND=" abi_x86_32? ( foo ? ( dev-libs/c[abi_x86_32(-)] ) )"

Because if you personally don't want foo on x32, and nothing needs foo
on x32, but you want foo on x64 , you have to have foo on x32 as well.

In that, if you specify USE="foo", the useflag will uncontrollably
apply to all ABIs that support that.

And you can't circumvent that without having something insane like
IUSE="foo_x86 foo_amd64 "

So if you wanted:
   package ABI= x86 USE= -foo
   package ABI= amd64 USE=foo

You cannot, you can only have

   package ABIs = x86, amd64, USE=foo

or

   package ABIS = x86,amd64, USE-foo

And this means if you didn't want foo on x86, you get it anyway, and
you get the unnecessary dep to support something you didn't want or
need.


-- 
Kent

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Sergey Popov]

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

14.11.2013 01:22, Kent Fredric пишет:
> +1 to that, I was going to suggest something similar to help explain
> what "~(foo)" means at least till people get used to it
> 
> e.g.
> ---
> The Following Use Flags were user set, but ignored due to stability masks:
>    dev-baz/quux: +foo -bar +baz
> 
> man emerge and grep for "stable use masks"
> ---
> 
> Or something. Maybe only shown with -v , or something so its not too
> annoying if users are ok with ignoring it.
> 

I like this idea too!

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[hasufell]

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

On 11/16/2013 11:57 AM, Thomas Sachau wrote:
> Pacho Ramos schrieb:
>> El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió:
>>> Dnia 2013-11-15, o godz. 14:53:00 Ben de Groot
>>> <yngwin@gentoo.org> napisał(a):
>>> 
>>>> As I see it now, with respect to multilib, we have three
>>>> competing solutions, but not a clear direction which way we
>>>> want to go as a distro:
>>>> 
>>>> 1: emul-* packages
>> 
>> This is the current option but has important drawbacks: - Each
>> emul set contains a ton of packages, then, when a security issue 
>> arises in one of them, we need to release a new
>> emul-linux-x86-... - It's built from stable tree, it can then
>> cause inconsistencies when people run native lib from testing (I
>> remember pulseaudio case) - If we would like to really follow
>> stabilized packages, we would nearly need to generate a new set
>> every week because likely some of the contained packages will be
>> stabilized on x86 so often. - As they are a big set of packages,
>> people need to install a lot of stuff they don't really need
>> 
>> In summary -> they are completely unflexible, with the problems
>> it cause
>> 
>>>> 2: multilib-portage
>> 
>> I think this has been discussed multiple times, if I don't
>> misremember, PMS team is not willing to accept it until the
>> specification is done... and we are waiting for that for years
>> probably because it includes a lot of changes (well, Tommy will
>> know much more about this)
> 
> Ever tried to write a formal spec in a foreing language? Creating 
> multilib-portage was easier then this request....
> 
> Anyway, the new multilib eclasses had no entrance barrier, so have
> been added and effectively everyone is forced to use them.
> 
> Since i dont expect anyone to vote for a different solution in the 
> future, which would force all multilib related parts to be
> rewritten, i stopped my work on the spec part. If anyone wants to
> continue that road, i can hand over any pieces i already have.
> 
> Instead i will simply prepare/maintain multilib-portage as a 
> portage-only package manager based multilib solution, which
> requires no changes to ebuilds. This also keeps a choice for users,
> who cant or dont want to convert all needed ebuilds to the new
> multilib eclasses.
> 
> 


multilib eclasses as a whole were a big failure, both for users
(enough examples given here) and for developers (cause it requires
understanding the eclasses).

You should keep working on the spec, so we might be able to remove
that crap some day.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSiOomAAoJEFpvPKfnPDWzTRUH/j5tWONLBh1bxCrsayrztYqn
GbK7Fz8RBTnkoJhmYX8InKh8USEyCY9fkRcxWgF2rcF801u8hhFwpXEzf5kTISMb
ctshmuyY5pS8e9IavyYY6VOTGmT2p9rxMpBVoDMn6Jf3hDwA2T/cY+W/QE1UGPF2
WVmdUAGFjPEaVJzMkgEgkCtoPhlqmPpHXrmhMKUvMNOtTdyNKSpqy+/ViUSZPp+J
zkHg3UyO5ROF0OTgXJLFT4gx+yR85b8IHrBdcfoAXFaAw7AU1ycJuZ2zHDCgzcjC
X4YTdSDoUAbxUpXf3cab13wRnudsGDUPfXD8lIb/20aPHnkKgjlHl+Otp3AnYco=
=tTTR
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Sun, 17 Nov 2013 17:09:10 +0100
hasufell <hasufell@gentoo.org> wrote:

> multilib eclasses as a whole were a big failure, both for users
> (enough examples given here)

You mean those failures where they mix branches and thus cause blockers
between the old and new approach? Those failures have nothing to do
with multilib eclasses, but rather by not understanding Portage's
complexity; it works for me and I don't see a problem, I don't mix.

> for developers (cause it requires understanding the eclasses).

Are you able to contribute anything without understanding any eclass?

> You should keep working on the spec, so we might be able to remove
> that crap some day.

Maybe, maybe not; you are replacing complexity by other complexity, now
the real question is rather where we want this complexity to be.

Multilib eclasses make bugs explicit and thus easier to find and fix.

Multilib Portage takes bugs away from the eclasses and ebuilds such that
they sit in Portage; this can be an advantage or disadvantage depending
on how you look at it, but it however does mean that this need continued
maintenance after this feature has been added to Portage.

With the lower Portage development activity, is that a viable option?

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJSiPBTAAoJEJWyH81tNOV9QzcH/jS0X0nSCZRhPXYbwRr6xuBg
vD5XCOwAbNHsEVfTo8kPpscvXsej4DQvvsVDGtCJEXlhO7pS4n9ArTEeeihVtgBI
hqycMrnr1cJ2IdT8KGNn+56WfgIQW9KP02gtZkfoClUzzT0kXr4zX1oVvHY7NLd6
CIFBIQHh4oUs1wHg7OkkrZeWzQJNTRs4Uws6FGIF4L3+durbvLdwmF1WN8YzayTe
6hHOWTEzAXVAeh+cnkhhaJyjmBlpUNqMNG4JZ5OO50vu18YbK5cPRvMdUws3Rsw4
NGFMaEna5JqMSUA5yevdDVzXtkZzqtZUymSFMxcm5Kt5oXPofo9zPIOh3/2tAXk=
=n44F
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Ciaran McCreesh]

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

On Sat, 16 Nov 2013 11:57:23 +0100
Thomas Sachau <tommy@gentoo.org> wrote:
> >>> 2: multilib-portage
> > 
> > I think this has been discussed multiple times, if I don't
> > misremember, PMS team is not willing to accept it until the
> > specification is done... and we are waiting for that for years
> > probably because it includes a lot of changes (well, Tommy will
> > know much more about this)
> 
> Ever tried to write a formal spec in a foreing language?

You weren't asked to write a formal spec. You were asked to provide
enough information so that someone else could do that.

> Creating multilib-portage was easier then this request....

Had you kept track of what changes you made and why you made them when
writing multilib-portage, we'd not have this problem.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
>
>> If this is not very hard to implement in portage, I would
>> strongly vote to remove this implicit connection:
>
> Not really doable since this is explicitly defined as such in EAPI=5 PMS.
>
> Retroactively changing PMS is probably not a good idea.

So keeping PMS is more important than usability?
Great!  One must know where to put emphasis and keep
an unfortunate chosen detail forever (or, as experience
concerning EAPI upgrades shows, at least for decades)
in order to fulfill a nonsense bureoucracy which probably
at most 3 packages use, currently.  Certainly, this is
more important than user experience!

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-17, o godz. 17:04:17
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> napisał(a):

> Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> > Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
> >
> >> If this is not very hard to implement in portage, I would
> >> strongly vote to remove this implicit connection:
> >
> > Not really doable since this is explicitly defined as such in EAPI=5 PMS.
> >
> > Retroactively changing PMS is probably not a good idea.
> 
> So keeping PMS is more important than usability?
> Great!  One must know where to put emphasis and keep
> an unfortunate chosen detail forever (or, as experience
> concerning EAPI upgrades shows, at least for decades)
> in order to fulfill a nonsense bureoucracy which probably
> at most 3 packages use, currently.  Certainly, this is
> more important than user experience!

And what does quickly removing used feature gain us in terms of
usability? You seem to be thoroughly ignoring the reasons and benefits
of stable.mask and just focusing on your pretty mixed-arch system. You
are willing to sacrifice the quality of stable tree for the sake of
a solution that is not even officially yet you believe everyone uses it.

Furthermore, some people think that issues are to be fixed. And by
fixed I mean the actual issues, not the whole component that is having
them. If we were to randomly choose a component that is involved in
your issues, we may as well remove support for mixing stable
and unstable packages. In fact, this will more likely fix a few more
bugs!

And something small at the end: if your hand hurts (it's the issue),
do you 'fix' the pain or do you cut the hand off?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Sun, 17 Nov 2013 17:04:17 +0000 (UTC)
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:

> Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> > Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
> >
> >> If this is not very hard to implement in portage, I would
> >> strongly vote to remove this implicit connection:
> >
> > Not really doable since this is explicitly defined as such in
> > EAPI=5 PMS.
> >
> > Retroactively changing PMS is probably not a good idea.
> 
> So keeping PMS is more important than usability?

Being supported is more important than running into breakage.

> Great!  One must know where to put emphasis and keep
> an unfortunate chosen detail forever (or, as experience
> concerning EAPI upgrades shows, at least for decades)
> in order to fulfill a nonsense bureoucracy which probably
> at most 3 packages use, currently.  Certainly, this is
> more important than user experience!

Does support increase user experience? What about breakage?

Let's say I want to have PM support for bug #449094 and do bug #472906.
I can go introduce eapi-5-kernel, which implements virtual sub slot
pass-through; which is so incredibly nice as it rebuilds external
kernel modules when you build a new kernel, sub slot rebuild style. 

But nobody really backs me up as it is not really standard, apparently
it then breaks for other kernels in the Portage tree. And as nobody
agreed on it, it can't be supported; because with its design certain
cases have not been taken into account. So, let's not rush this magic
eapi-5-kernel feature and do it properly as part of eapi-6 or later.

Rather have a handful of supported EAPIs than hundreds of unsupported
EAPIs. The supported ones work; as for the unsupported ones, I doubt it.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 872 bytes --]

Am Samstag, 16. November 2013, 13:58:48 schrieb Michał Górny:
> Dnia 2013-11-16, o godz. 13:50:11
> 
> "Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):
> > Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
> > > Probably a lot of the confusion could be avoided if
> > > /etc/portage/package.accept_keywords would not implicitly
> > > unmask useflags.
> > 
> > How would you handle the case if a package has only one version in
> > portage and that one is stable?
> 
> Unmask it through use.stable.mask and package.use.stable.mask
> in /etc/portage/profile?
> 
> Then we clear separation between masked packages and masked flags.

Not practical... Maintainer has to modify profile files then for each and any 
stable request.


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-17, o godz. 19:13:59
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> Am Samstag, 16. November 2013, 13:58:48 schrieb Michał Górny:
> > Dnia 2013-11-16, o godz. 13:50:11
> > 
> > "Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):
> > > Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
> > > > Probably a lot of the confusion could be avoided if
> > > > /etc/portage/package.accept_keywords would not implicitly
> > > > unmask useflags.
> > > 
> > > How would you handle the case if a package has only one version in
> > > portage and that one is stable?
> > 
> > Unmask it through use.stable.mask and package.use.stable.mask
> > in /etc/portage/profile?
> > 
> > Then we clear separation between masked packages and masked flags.
> 
> Not practical... Maintainer has to modify profile files then for each and any 
> stable request.

Excuse me, but why in the world would maintainer unmask stable-masked
flags when stabilizing a package? This doesn't really seem meaningful,
and also means the maintainer will try to stabilize dependencies which
aren't meant to go stable yet... 

-- 
Best regards,
Michał Górny

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

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Michał Górny <mgorny@gentoo.org> wrote:
> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> napisa=C5=82(a):
>
> And what does quickly removing used feature gain us in terms of
> usability?

We are talking about changing a detail of a feature which just has
proven that it is causes dependency chaos due to a side effect of
that detail which probably nobody had thought of when it was
introduced. Instead of fixing that detail which would need a
rewording of PMS and a change in 2-3 package managers, you think
it is better to keep the issue ... the reason being just
bureaucracy.

> Furthermore, some people think that issues are to be fixed.

Yeah, spend years to look for the theoretically best matching
solution instead of making things working.  Like Hurd.
Gentoo usually had the courage to try things (like multiarch
support); and if they turned out to be bad to modify/withdraw
them (like USE-flags triggered by installed packages).
Now a bureaucracy has taken over which forbids this?

> we may as well remove support for mixing stable
> and unstable packages. In fact, this will more likely fix a few more
> bugs!

Yes, it will fix bug reports of most users, since they are
moving then to another distro.

> And something small at the end: if your hand hurts (it's the issue),
> do you 'fix' the pain or do you cut the hand off?

I will fix the pain instead of following some paper where it
is written that I must not touch my hand with a knife or whatever.
And also, I would not start to build a better hand which can
eventually replace my older one without the pain, as soon
as the older one has died off.

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Ian Stakenvicius]

On 2013-11-17, at 12:04 PM, Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:

> Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>> Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
>> 
>>> If this is not very hard to implement in portage, I would
>>> strongly vote to remove this implicit connection:
>> 
>> Not really doable since this is explicitly defined as such in EAPI=5 PMS.
>> 
>> Retroactively changing PMS is probably not a good idea.
> 
> So keeping PMS is more important than usability?
> Great!  One must know where to put emphasis and keep
> an unfortunate chosen detail forever (or, as experience
> concerning EAPI upgrades shows, at least for decades)
> in order to fulfill a nonsense bureoucracy which probably
> at most 3 packages use, currently.  Certainly, this is
> more important than user experience!
> 
> 


I assume this is about the *.use.stable.mask files ...  we don't need to retroactively remove them from PMS, we just set a portage tree policy to leave them empty and ask everyone to not use it.  PMS stays the same, support in package managers stays in, but the feature is effectively removed due to not being used.  same end result without the breakage.

that said, I still support *.use.stable.mask and would not like to see it removed or banned.

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Tom Wijsman <TomWij@gentoo.org> wrote:
> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
>>
>> So keeping PMS is more important than usability?
>
> Being supported is more important than running into breakage.

What has a line in PMS which has practically no influence
on anybody except for breaking user experience have to do
with "being supported"?
Does any developer's life change so bad that he cannot
support it anymore if the package manager no longer gives
misleading errors to the user?

> Does support increase user experience? What about breakage?

Yeah, treating user-config files in a clearer way will break things
horribly.  Better question: What about the breakages which the
side effect of package.accept_keywords has just proven to cause?

> Let's say I want to have PM support for bug #449094 and do bug #472906.

You proved that you can find modifications of PMS which obviously
can have bad side effects in certain situations. And so what?
I am not going to kick your strawman.

> So, let's not rush this magic
> eapi-5-kernel feature and do it properly as part of eapi-6 or later.

Sure, introducing a new feature can wait until the involved
packages provide the new EAPI.
But the dependency breakage of the side effect we are talking
about will stay as long as at least one package in the dependency
chain is not EAPI=6 or newer, i.e. "not rushing" in your term
means waiting for ... 10 years? ... 20 years? ...forever?
This is simply not an appropriate way how to deal with problem
when they turn up in an already released EAPI. Especially not,
if it is such a tiny issue which can be fixed by reformulating
one or two lines just with having the side effects in mind
(which had probably surprised everybody - including myself -
in this consequence).

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Ian Stakenvicius <axs@gentoo.org> wrote:
>>> Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
>>> 
>>>> If this is not very hard to implement in portage, I would
>>>> strongly vote to remove this implicit connection:
>
> I assume this is about the *.use.stable.mask files ...

Even less: The discussion in this part of the thread was
only about the implicit connection of package.accept_keywords
with *use.stable.mask, i.e. about removing the
side effect of unmasking USE-flags by these files.

> we don't need to retroactively remove them from PMS,
> we just set a portage tree policy to leave them empty
> and ask everyone to not use it.

As I understand, this would not find any majority since
developers want faster stabilization paths.
I think one can live with it if it does not cause the
dependency hell - and this can be avoided by removing
mentioned side effect. But if done only for EAPI=6 or
newer packages, in practice this side effect will remain
forever.

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Michał Górny]

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

Dnia 2013-11-17, o godz. 19:18:35
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> napisał(a):

> Ian Stakenvicius <axs@gentoo.org> wrote:
> >>> Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
> >>> 
> >>>> If this is not very hard to implement in portage, I would
> >>>> strongly vote to remove this implicit connection:
> >
> > I assume this is about the *.use.stable.mask files ...
> 
> Even less: The discussion in this part of the thread was
> only about the implicit connection of package.accept_keywords
> with *use.stable.mask, i.e. about removing the
> side effect of unmasking USE-flags by these files.

Oh, then it doesn't have to do anything with PMS. Portage config files
are purely a choice of portage developers, and this can be done as soon
as you convince them this is the right thing to do. I've tried [1].

[1]:https://bugs.gentoo.org/show_bug.cgi?id=491166

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[hasufell]

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

On 11/17/2013 07:46 PM, Martin Vaeth wrote:
> Michał Górny <mgorny@gentoo.org> wrote:
>> we may as well remove support for mixing stable and unstable
>> packages. In fact, this will more likely fix a few more bugs!
> 


It was never "officially" supported. That doesn't mean we have to
break it, just because we introduced some misdesigned ideas.

Design decisions should be based on what a) makes ebuild development
easier and b) benefits the user.

Currently there are a lot of things where gentoo devs are forced to
follow design decisions that turned out different than expected... and
the users pick up the pieces.

I'm not saying everything of that was forseeable. But it's slipping
out of control. It just took me another 30minutes to update a gentoo
box which I do not log into very often. I got trapped between python
blockers, multilib blockers, a confused portage with wrong autounmask
messages and some other things that could not be resolved
automatically at all.

Users should not be forced to micro-manage all sorts of stuff for a
simple update.

But yeah... let's just say we don't support custom useflag settings
anymore, because it's so much easier then and would fix a LOT of bugs.

Nice going.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSiRnXAAoJEFpvPKfnPDWzBgEH/Ag3/pZohijH0Nn2Vkr3Jq51
RIBsj11zeu0xWO+wztiZgpY6MvnVbondoTZAcx5JIuTqY9RB12oelRl6R0ZtBlSR
Q5idRFzO+w2RgUp0bLpD4H4fkV8vrcOcsZlysaz5jnpmHYOMTghGgfd5EgQx4qw3
YQnFUTDzoYBcsY6jbndqWQrWRCekTsUAPPiqZkocEgBOiRu3awLtbVbz5JB5jWRL
o/fGpn3d5qEvelTSYLU7R1vqhxAFY6SeYPt/ewCC/tkNlNJJ2NsvSCvfYd6mgUC5
BCnXA9fUGvKqoGhGx2rn+JjgoyBxTvUAQFHEae4aFsKTF4WehvO7Gx53YSo3HIw=
=6WzP
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

Michał Górny <mgorny@gentoo.org> wrote:
> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> napisa=C5=82(a):
>> Even less: The discussion in this part of the thread was
>> only about the implicit connection of package.accept_keywords
>> with *use.stable.mask, i.e. about removing the
>> side effect of unmasking USE-flags by these files.
>
> Oh, then it doesn't have to do anything with PMS. Portage config files
> are purely a choice of portage developers, and this can be done as soon
> as you convince them this is the right thing to do.

I also thought so, first, but unfortunately PMS is here clear
in its formulation:

"... package.use.stable.mask ... do the same thing [as package.use.mask].
These files, however, act only on packages which are merged due to a
stable keyword..."

There is no distinction about the location where the permission
to install an unstable keyword comes from.

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Sun, 17 Nov 2013 19:10:21 +0000 (UTC)
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:

> Tom Wijsman <TomWij@gentoo.org> wrote:
> > Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> >>
> >> So keeping PMS is more important than usability?
> >
> > Being supported is more important than running into breakage.
> 
> What has a line in PMS

You can suggest such line change on the gentoo-pms mailing list;
when you do that, I can understand which change you try to refer to.

(Note that this translates to multiple changed lines in each PM)

> which has practically no influence

Specifications need to work on the theoretical side too; if it works in
practice for you, it can sill have practical implications on other
consumers. It is a dangerous assumption to think different.

> on anybody except for breaking user experience have to do
> with "being supported"?

Two sentences appear to be mixed here, do you suggest that the line
change "breaks user experience"? The PMS is what we agree to and what
we support, anything else that breaks follows something different than
the PMS and is outside the boundaries of its associated support.

> Does any developer's life change so bad that he cannot
> support it anymore if the package manager no longer gives
> misleading errors to the user?

Output of the package manager itself is outside the scope of the PMS.

> > Does support increase user experience? What about breakage?
> 
> Yeah, treating user-config files in a clearer way will break things
> horribly.

Changes indeed bring along bugs and breakage; which you need to take
into account when doing risk assessment, going for the advantages it
brings only works out if you consider whether disadvantages bug you.

> Better question: What about the breakages which the
> side effect of package.accept_keywords has just proven to cause?

What about replacing known breakages by unknown breakages?

> > Let's say I want to have PM support for bug #449094 and do bug
> > #472906.
> 
> You proved that you can find modifications of PMS which obviously
> can have bad side effects in certain situations. And so what?
> I am not going to kick your strawman.

Can you proof that your line change only has good side effects?

> > So, let's not rush this magic
> > eapi-5-kernel feature and do it properly as part of eapi-6 or later.
> 
> Sure, introducing a new feature can wait until the involved
> packages provide the new EAPI.
> But the dependency breakage of the side effect we are talking
> about will stay as long as at least one package in the dependency
> chain is not EAPI=6 or newer, i.e. "not rushing" in your term
> means waiting for ... 10 years? ... 20 years? ...forever?

It needs a clairvoyant to tell, PMS changes on their own take some time;
and even if we could get it done before the end of the month, consider
that the package managers are currently undermanned. If you want to see
a solution soon, changing the PMS does not feel like a the way to go.

> This is simply not an appropriate way how to deal with problem
> when they turn up in an already released EAPI. Especially not,
> if it is such a tiny issue which can be fixed by reformulating
> one or two lines just with having the side effects in mind
> (which had probably surprised everybody - including myself -
> in this consequence).

It will be discussed, rewritten, voted upon, added, then the EAPI gets a
new revision / release; after that, actively used Package managers need
to implement it (which is not necessarily a single line change),
releases need to be made for these Package managers as well, those
releases need to be stabilized; at this point, the Council needs to
declare the new version for use after which the Portage tree migrates
to it (assuming the EAPI change brings along other fixes as well).

It's a bit more involved than a reformulation, it takes time...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Tom Wijsman]

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

On Sun, 17 Nov 2013 20:32:39 +0100
hasufell <hasufell@gentoo.org> wrote:

> >> we may as well remove support for mixing stable and unstable
> >> packages. In fact, this will more likely fix a few more bugs!
> 
> It was never "officially" supported. That doesn't mean we have to
> break it, just because we introduced some misdesigned ideas.

Does that mean we can actively encourage users to use it? Is its
existence an indication of it being a good designed idea? Is Portage
designed with heavily mixing software branches in mind? 

> Design decisions should be based on what a) makes ebuild development
> easier and b) benefits the user.

Mixed software branches have a lot of untested scenarios, some devs drop
bugs for them and it has caused a lot of bugs, conflicts and blockers;
I doubt if mixing software branches makes ebuild development easier or
benefits the user. It is quite the opposite, it requires more work from
the developers and has caused a ton of headaches for our users.

> Currently there are a lot of things where gentoo devs are forced to
> follow design decisions that turned out different than expected... and
> the users pick up the pieces.
>
> I'm not saying everything of that was forseeable. But it's slipping
> out of control. It just took me another 30minutes to update a gentoo
> box which I do not log into very often. I got trapped between python
> blockers, multilib blockers, a confused portage with wrong autounmask
> messages and some other things that could not be resolved
> automatically at all.

Mixed software branches fit this description.

> Users should not be forced to micro-manage all sorts of stuff for a
> simple update.

Updates are simple in stable or unstable, but not in a mix of them.

> But yeah... let's just say we don't support custom useflag settings
> anymore, because it's so much easier then and would fix a LOT of bugs.

The same could be said about mixed software branches.

> Nice going.

We're going both ways; Gentoo's choice you to go one way, or the other.

PS: I'm not personally against this "mixed software branches" feature.
It can work out if you know about the complexity involved and know the
background of that complexity; but for the average user, this is to be
used sparingly. Pure stable and unstable has always worked fine for me.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJSiSQiAAoJEJWyH81tNOV9OfwIAKhBGat3MUlwZQnTFpFXskHk
UaEwnPGWLh1qN8ScSSnDiExar1qEI8dI4UI6p9crjawEdGhXK+g4DdMuiMa2YbBN
UzsOmcOBEpH7zqeRPFjqa8HQ7iAdPfaUwiBM5hOM2lD3hV9jRCK4CZQsMpnnx+Kc
B7opACMXA2M721nstcuEu+SCT8xMT1wPbT25XntKNVBDafrOBwSDsnLUCGKymOF5
YgMHp5sOUSvFhqV1vPN8SbM++JByTlcwV7vuIR6NkbbhOLhaz3S5F/tJGnvuHPSB
bqydOcBpnzeNf74xD9yumXzAI8npmconeAJ1nzsYUR2Jt+tHeCO9hWMUQm+695s=
=XzNX
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1146 bytes --]

Am Sonntag, 17. November 2013, 20:51:36 schrieb Martin Vaeth:
> Michał Górny <mgorny@gentoo.org> wrote:
> > Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> napisa=C5=82(a):
> >> Even less: The discussion in this part of the thread was
> >> only about the implicit connection of package.accept_keywords
> >> with *use.stable.mask, i.e. about removing the
> >> side effect of unmasking USE-flags by these files.
> > 
> > Oh, then it doesn't have to do anything with PMS. Portage config files
> > are purely a choice of portage developers, and this can be done as soon
> > as you convince them this is the right thing to do.
> 
> I also thought so, first, but unfortunately PMS is here clear
> in its formulation:
> 
> "... package.use.stable.mask ... do the same thing [as package.use.mask].
> These files, however, act only on packages which are merged due to a
> stable keyword..."
> 
> There is no distinction about the location where the permission
> to install an unstable keyword comes from.

Yep. I wrote that.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]