Portage 2.1 'autouse' flags - now what

zmedico · Posted: Sun Jun 11, 2006 7:50 pm Post subject:

I've added an einfo to the ebuild in order to ease the migration. Here it is:

Bloody100 · n00b Joined: 02 Apr 2006 Posts: 7 Location: Berlin

Thanks for the answer, but forgive me if i ask if this is the way how users are guided thru' update problems - by posting a comment on page two of some forum thread?

May i suggest to add an interactive mode to portage which causes emerge to stop & ask the user if any kind of warning, error or other glitch occurs?

For example:

emerge -uDNa world --interactive

emerging portage....

Warning: new USE flags behavior, please do this and that before going on.

Here's a list of USE vars which are no longer automatically used:

bzip2
samba
...

Continue? (y/N) _

Even better: automatic problem solving, like this:

emerge -uDNa world --autofix

emerging portage...

warning: new USE flags behavior, blablabla,

the following USE flags are no longer automatically set:

bzip2
samba
...

do you wish to add the mentioned vars to /etc/make.conf? (Y/n) _

Y

adding USE vars...
resuming emerge...

Further examples:

emerge -uDNa world --autofix

emerging shadow..

auto-fixed: pam-login uninstalled because it's obsolete and superseded by 'shadow'.

...and another:

emerge -uDNa world --interactive

emerging firefox...

warning: firefox ~arch version is going to be installed, but this time it requires
a version of dev-libs/nspr which is currently marked ~arch as well.

shall i use ~arch for dev-libs/nspr as well this time? (Y/n) _

...the --autofix version:

emerge -uDNa world --autofix

emerging firefox...

auto-fixed: emerged ~arch version of dev-libs/nspr this time in order to install current ~arch version of firefox.

I'm willing to put a bet on the assumption that if x.org 7 is marked stable, the update will cause forum studies again..

_________________
Cheers,

Oliver 'Bloody' Lange.

Mark Clegg · Posted: Mon Jun 12, 2006 7:16 pm Post subject:

Thanks zmedico - that looks just the ticket to me.

csab · Posted: Mon Jun 12, 2006 7:52 pm Post subject:

Bloody100, I don't like your ideas at all. I use Gentoo to have full control. I would hate any "automatic" solution, like unistalling pam automatically or modifying /etc/make.conf. I would always run interactive mode then, and probably say "no" to every question before I find out what it means.

I've heard that there is an operating system for PCs for a moderate price in which you only have to turn on "automatic updates" and everything will be taken care of. You will never know what goes on under the hood, but if you don't care, it may be the best solution for you.

Bloody100 · n00b Joined: 02 Apr 2006 Posts: 7 Location: Berlin

I agree to the point that Gentoo users like the high level of customization, but i'd say your reaction is a bit exaggerated.

Remeber that Gentoo claims to be an ultimate-flexible Linux distro which shall fulfil ALL users demands, so if
one (me) wishes to avoid studying forums every Nth update, then this is what i expect from an ultimately flexible system,
but if Gentoo isn't able to meet these common high standards of other systems (i assume you mean Windows but there
are also several Linux distros which do), then Gentoo Linux just isn't that flexible as promised because it only fits the
needs of a few geeks but not the majority of users, rendering Gentoo Linux a minor distro for only a few people.
I'd very like the idea of recommending my favorite Linux distro to everyone! Unfortunately, i can currently only
tell most people to stay away from Gentoo.

I can understand that you won't use the --autofix feature, but 1000 users mean 1000 opinions and prefs, right...

As a programmer, i can absolutely understand that meeting such high standards with such a flexible distro, adds
an extreme amount of additional work, covering all possible problems that may break the update procedure, but i would
not predicate that this must necessarily reduce the flexibility of a system or application. It's 'just' about extra work to do.

The point in my previous post is that portage could inform a user about the exact problem asap while the update
is running instead of leaving him/her alone until (hopefully) the next weekly Gentoo newsletter contains a side-note
about the recent problems with the latest updates. Just mentioning flexibility as excuse for frequent update struggle is
IMHO not exactly a satisfying solution. If something is changed in a Linux distro, maintainers should know that these
changes must and will cause trouble, and offer a way to solve these things before releasing an update, maybe by using
a combined interactive-autofix mode, where the user is prompted to either continue, auto-fix the problem or stop
emerging for an attempt to fix the issue(s) manually.

Now i've followed the hint above from zmedico and entered the mentioned portageq command. The output contained
things like "elibc_glibc kernel_linux linguas_de linguas_en userland_GNU" and the like. Especially the "linguas_xy" parts
seem to be unneeded since i've defined LINGUAS="de en" already. Doesn't that render the LINGUAS var obsolete?

And what about Gentoo 2007.0? Will there be a note in the install guide about adding tons of USE vars like "userland_GNU"
to their make.conf before going on?

What if the Gentoo devs decide not to use things like "userland_GNU" anymore or if such low-level things are e.g. renamed
in the future? Of course i've added everything to my make.conf now, but somehow i've got the feeling that /etc/make.conf
is not the very best place for such basic things because i assume that the Gentoo system would prefer to control this stuff
itself and therefor i expect further issues in the future. The point here is that most users will probably want to keep their
Gentoo base system as unmodified as possible to avoid running into problems caused by unusual system settings which
are unexpected by portage, just because one has followed the wrong hint in the wrong forum thread, written by some
non-developer who found (and posted) a questionable solution...

This is not just about the current portage update. IMHO, it's a general Gentoo problem (frequent update issues which are
solved by 1000 users in 1000 different ways) which is likely to break a noticeable percentage of Gentoo installations now or
in the future, causing many users to switch to another distro, no matter how deeply in love with Gentoo.

Cheers...

_________________
Cheers,

Oliver 'Bloody' Lange.

zmedico · Posted: Mon Jun 12, 2006 9:45 pm Post subject: Re: suggestion

Viaken · n00b Joined: 18 Jan 2006 Posts: 8

Following this discussion and the links, basically the devs decided autouse is confusing and unnecessary. I always found it rather intuitive, but what do I know?

The long and short of it is: Until the devs get rid of use.defaults, the quick fix is to add the following to your make.conf:
USE_ORDER="env:pkg:conf:auto:defaults"

Works For Me. (tm) (But the plan seems to be to make us to manually define the USE flags we want eventually, it seems, so this could stop working without warning.)

zmedico · Posted: Wed Jun 14, 2006 9:08 am Post subject:

TGL · Posted: Wed Jun 14, 2006 7:35 pm Post subject:

MooNz · n00b Joined: 08 Dec 2003 Posts: 5

I've relied on autouse feature, intensionally because it was what I exactly wanted---to fully enable the extra features that utilize installed packages.

Yes, many people don't want this. Sure, it can be very bothering to those people.
But it's a invaluable FEATURE that other people, like me, can't live without.

So changing the default not to use autouse is OK.
But, deprecating it permanantly? Plz, don't lose this great feature.

zmedico · Posted: Thu Jun 15, 2006 7:51 am Post subject:

Genone · Posted: Thu Jun 15, 2006 1:58 pm Post subject:

The main reason for disabling/removing/deprecating autouse (besides causing confusion for some users and a general dislike of automagic) is that it makes it quite hard to get a really deterministic and complete dep resolver on a conceptual level. Not something users will typically notice but gives you a headache whenever you think about it.

Necoro · Veteran Joined: 18 Dec 2005 Posts: 1912 Location: Germany

TGL · Posted: Thu Jun 15, 2006 7:03 pm Post subject:

NightMonkey · Posted: Sun Jun 18, 2006 12:37 am Post subject: portage-features mailing list?

Hi, all. Just a "me too" here - I've been bitten by this Portage feature change. Not too disruptive, but was a head-scratcher to figure out why suddenly all of the basic USE flags that I had relied on just vanished. Is there a "portage-features" announcement-only mailing list? What I'd envision for this list is just announcements of major feature changes in Portage, alerting users to functionality changes that are imminent upon the next Portage update. Among the many choices for updating users to critical changes, I think e-mail might be the best method, over an in-Portage einfo mechanism ("Hmm... I missed that line in the hundreds of lines that just passed by while I went shopping."), the Forums ("Didn't see that post that is now on page 3 of the "Portage" forum"), or the -dev lists ("That was announced seven gentoo-dev digests ago, you cretin!").

Thanks for reading this.
_________________

NightMonkey · Posted: Sun Jun 18, 2006 12:54 am Post subject:

Here's a Quick and Dirty way to give you back what you have lost from this change. I took the comparative mechanism posted above, and added a bit more. Note that this requires gentoolkit.

csab

Daniel Tourde - Caelae.se

OK,

There are basically two schools to get back the missing flags (the one in the second columnn under ufed):
- Add them all manually in make.conf (with ufed for instance)
- Add USE_ORDER="env:pkg:auto:conf:defaults" to the make.conf file

I personnaly chose the second one... I am lazy...

'portageq envvar USE_ORDER'
tells how the USE_ORDER looks like

Edit: Merged with this thread. --Maedhros