Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 258371 (autouse) - add emerge option to automatically satisfy USE dependencies
Summary: add emerge option to automatically satisfy USE dependencies
Status: IN_PROGRESS
Alias: autouse
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High enhancement with 16 votes (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 256519 294162 454270 454580 459344 543994 584430 599208 (view as bug list)
Depends on: 651374 137562 280097 582624
Blocks: 155723 300071 359659 388267
  Show dependency tree
 
Reported: 2009-02-09 21:03 UTC by Pacho Ramos
Modified: 2020-03-28 20:35 UTC (History)
37 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos gentoo-dev 2009-02-09 21:03:07 UTC
When I run emerge -avuDN world I get:
 # emerge -avuDN world

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

Calculating dependencies... done!

emerge: there are no ebuilds built with USE flags to satisfy ">=media-libs/sdl-mixer-1.2.4[mikmod,mp3,timidity]".
!!! One of the following packages is required to complete your request:
- media-libs/sdl-mixer-1.2.8 (Change USE: +timidity)
(dependency required by "games-arcade/rocksndiamonds-3.2.6.0" [ebuild])
(dependency required by "world" [argument])

I would expect emerge to simply re-emerge sdl-mixer with requested USE flag, as I don't have "-timidity" neither in make.conf nor in package.use

My emerge --info:
Portage 2.1.6.4 (default/linux/amd64/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.28-tuxonice-r1 x86_64)
=================================================================
System uname: Linux-2.6.28-tuxonice-r1-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T9300_@_2.50GHz-with-glibc2.2.5
Timestamp of tree: Mon, 09 Feb 2009 20:30:01 +0000
distcc 3.0 x86_64-pc-linux-gnu [disabled]
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p39
dev-java/java-config: 1.3.7-r1, 2.1.6-r1
dev-lang/python:     2.5.2-r7
dev-util/ccache:     2.4-r7
dev-util/cmake:      2.4.8
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.63
sys-devel/automake:  1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=nocona -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -pipe -march=nocona -fomit-frame-pointer"
DISTDIR="/usr/distfiles"
FEATURES="autoaddcvs ccache collision-protect cvs distlocks fixpackages multilib-strict parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org"
LANG="es_ES.UTF-8"
LC_ALL="es_ES.UTF-8"
LDFLAGS="-Wl,-O1"
LINGUAS="es es_ES en_US"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage/layman/sunrise /usr/local/portage/layman/wschlich-testing /usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi alsa amd64 amr avahi bash-completion berkdb bluetooth branding bzip2 cairo cdda cddb cdparanoia cdr cli consolekit cracklib crypt css cups daap dbus dell dirac divx djvu dts dvd dvdr dvdread dvi eds emboss emovix encode epiphany evo exif fam fbcondecor fbsplash ffmpeg flac fortran fuse galago gdbm gif glitz gmedia gnome gnome-keyring gpm gsm gstreamer gtk hal iconv ieee1394 ipv6 isdnlog java java6 jpeg jpeg2k kdeenablefinal kdehiddenvisibility kpathsea laptop latex lcms ldap libnotify lzma mad midi mikmod mjpeg mmx mmxext mono moonlight mp3 mpeg mudflap multilib musepack musicbrainz nautilus ncurses network network-cron networkmanager nls nptl nptlonly ntp ogg opengl openmp pam pch pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline realmedia reflection scanner schroedinger sdl session smp sms speex spell spl sse sse2 sse3 ssl ssse3 startup-notification svg sysfs t1lib tcpd theora threads tiff totem truetype unicode usb v4l2 vcd vorbis wmf wmp x264 xattr xcb xft xinetd xml xorg xulrunner xv xvid zeroconf zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es es_ES en_US" USERLAND="GNU" VIDEO_CARDS="nvidia nv"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS



Reproducible: Always
Comment 1 Zac Medico gentoo-dev 2009-02-09 22:08:11 UTC
I'll add an option for this. It has to be optional since emerge shouldn't necessarily assume that you want your USE flags automatically changed.
Comment 2 Pacho Ramos gentoo-dev 2009-02-10 08:11:01 UTC
Ah, OK, thanks a lot :-)
Comment 3 Steve Brudenell 2009-03-16 00:37:20 UTC
(In reply to comment #1)
> I'll add an option for this. It has to be optional since emerge shouldn't
> necessarily assume that you want your USE flags automatically changed.
> 

This may be a minor point, but I honestly believe that it should.

My evidence is:
 - More and more ebuilds these days have complex USE dependencies, which will in be seen by more and more users who will gain more and more benefit from not needing to worry about this magical option.
 - Gentoo already makes it perfectly clear that maintenance of USE flags is a user responsibility in every piece of documentation and example code.
 - USE flags are already automatically updated, by virtue of changing defaults at either the profile or ebuild level.
Comment 4 Steve Brudenell 2009-03-16 00:43:13 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > I'll add an option for this. It has to be optional since emerge shouldn't
> > necessarily assume that you want your USE flags automatically changed.
> > 
> 
> This may be a minor point, but I honestly believe that it should.
> 
> My evidence is:
>  - More and more ebuilds these days have complex USE dependencies, which will
> in be seen by more and more users who will gain more and more benefit from not
> needing to worry about this magical option.
>  - Gentoo already makes it perfectly clear that maintenance of USE flags is a
> user responsibility in every piece of documentation and example code.
>  - USE flags are already automatically updated, by virtue of changing defaults
> at either the profile or ebuild level.
> 

After sending this I realized I could have misinterpreted how this option would be implemented ... I would assume that with the new option enabled, the hierarchy of USE flags would now effectively be:

 1) $USE environment variable
 2) make.conf
 3) requirements from dependencies, if agrees with 1 or 2, else error
 4) defaults from ebuild, if nothing specified at 3
 5) defaults from make.profile, if nothing specified at 3 or 4

Is this what you had envisioned?
Comment 5 Zac Medico gentoo-dev 2009-03-16 01:10:22 UTC
I think there actually needs to be two different forms of this option:

1) Automatically adjust as long as it doesn't conflict with user configuration (settings in make.conf, /etc/portage/package.use, or the USE environment variable).

2) Automatically adjust, doing anything necessary to satisfy dependencies, regardless of user configuration.
Comment 6 Steve Brudenell 2009-03-16 01:50:27 UTC
(In reply to comment #5)

That does seem safe, but what would "anything necessary" entail? It seems that if there is no way to satisfy dependencies given user choices, there are several perfectly valid options. The user might choose to unmerge, ignore, mask, or unmask either the "new" package(s) (the one[s] introducing the conflicting dependency requirements) or the "old" package (the one[s] upon which the conflicting requirements are placed). If the user's selected USE flags are contributing to the conflict he might elect to simply change them.

Under what circumstances could portage make a reasonable decision between these options?
Comment 7 Malte E. 2009-03-26 14:21:57 UTC
(In reply to comment #1)
> I'll add an option for this. It has to be optional since emerge shouldn't
> necessarily assume that you want your USE flags automatically changed.
> 

I don't really get your point. If installing a package, the user is not asked whether he want's a dependency to be installed or not, he is just informed about it. Also, he would be informed about use flag changes. If he does not want packages to be installed/use flag changes to be made, he would try --nodeps or just not install the package. It does not make sense to abort the installation.

But I still support your idea of making it optional - so everybody can have it the way he preferres.
Comment 8 Zac Medico gentoo-dev 2009-03-26 21:45:50 UTC
(In reply to comment #6)
> That does seem safe, but what would "anything necessary" entail? It seems that
> if there is no way to satisfy dependencies given user choices, there are
> several perfectly valid options. The user might choose to unmerge, ignore,
> mask, or unmask either the "new" package(s) (the one[s] introducing the
> conflicting dependency requirements) or the "old" package (the one[s] upon
> which the conflicting requirements are placed).

I was only talking about USE flag adjustments. Unmasking would have to be triggered by a separate option, but the two options could be used together.

(In reply to comment #7)
> But I still support your idea of making it optional - so everybody can have it
> the way he preferres.

Well, changing defaults tends to annoy large numbers of people, so generally things like this are purely optional. You'll be able to add them to EMERGE_DEFAULT_OPTS if you want.
Comment 9 Malte E. 2009-10-11 14:20:41 UTC
Is there any progress on this? Just wondering, I'm not intending to annoy you guys ;)
Comment 10 Zac Medico gentoo-dev 2009-10-11 19:54:09 UTC
(In reply to comment #9)
> Is there any progress on this?

No, not yet. However, the backtracking code from bug 137562 helps, since the required flag settings can be gathered there and used for recalculating dependencies.
Comment 11 Zac Medico gentoo-dev 2009-12-07 09:17:47 UTC
*** Bug 294162 has been marked as a duplicate of this bug. ***
Comment 12 Walter 2010-01-07 14:06:45 UTC
Now that Bug 294162 is complete, is there any chance of movement on this one?

On the other hand if nobody has time and a developer wants to point me roughly in the right direction (and thinks it wouldn't be entirely difficult for a non-Pythoner - fluent perl+php/some ruby) to get their hands dirty I would be happy to try this one out myself...

Otherwise I am going to have to try duplicating the same functionality by wrapping existing tools, as explained @ Bug 294162
Comment 13 Zac Medico gentoo-dev 2010-01-07 19:31:35 UTC
(In reply to comment #12)
> Now that Bug 294162 is complete, is there any chance of movement on this one?

It's much more doable since bug 137562 has been fixed. See the relevant code in r13816:

 http://sources.gentoo.org/viewcvs.py/portage?view=rev&rev=13816
Comment 14 Zac Medico gentoo-dev 2010-07-16 18:27:37 UTC
*** Bug 328343 has been marked as a duplicate of this bug. ***
Comment 15 Zac Medico gentoo-dev 2010-08-12 12:54:19 UTC
The --autoumask option from bug 280097 can automatically generate package.use settings for you.
Comment 16 Zac Medico gentoo-dev 2011-03-20 21:19:49 UTC
*** Bug 256519 has been marked as a duplicate of this bug. ***
Comment 17 Martin von Gagern 2011-03-20 22:11:04 UTC
Why is this bug in the "Gentoo Linux" product of bugzilla, instead of "Portage Development" where bug #256519 was and where this imho belongs? I also wonder what changing the component will do to the votes...
Comment 18 Zac Medico gentoo-dev 2011-06-06 14:43:38 UTC
(In reply to comment #15)
> The --autoumask option from bug 280097 can automatically generate package.use
> settings for you.

This is enabled by default in portage-2.1.10. There's also a new --autounmask-write option can be used to have config changes automatically written to the appropriate files, repecting --ask and CONFIG_PROTECT (see bug 345775).
Comment 19 Zac Medico gentoo-dev 2013-01-27 19:49:15 UTC
*** Bug 454270 has been marked as a duplicate of this bug. ***
Comment 20 Zac Medico gentoo-dev 2013-01-29 23:09:43 UTC
*** Bug 454580 has been marked as a duplicate of this bug. ***
Comment 21 igel 2013-01-30 09:43:19 UTC
Neither --autounmask nor --autounmask-write provide the desired functionality, if I understood (and tested) correctly. Writing config files should not be necessary as long as a package that requires the USEflag in question is installed. I'll give my udev example again (as in Bug 454580):

"This should be done _without_ adding anything in /etc/portage/package.use, since this file is supposed to contain user preferences. If I don't want my udev with gudev any more, then removing gudev from virtual/udev should suffice to not require gudev on sys-fs/udev in future merges."

Regarding Comment 5: "Automatically adjust, doing anything necessary to satisfy dependencies, regardless of user configuration."
I don't think this is a good idea. If the user settings conflict with what needs to be installed to satisfy a user request, then the user made conflicting requests and needs to resolve the conflict in whatever way he likes (as pointed out by Comment 6). Maybe the user prefers not to install the package if it conflicts with a USEflag he specified in package.use...

Also, the link provided in Comment 13 is no longer valid.
Comment 22 Cedric Sodhi 2013-02-26 19:55:25 UTC
Bug 459344 was closed as a duplicate of #458464 which says, quote "no way to JUST DAMN INSTALL a package".

I take the liberty to change the reference to the bug here, for it seems to have higher resemblance.

I think that goes in the spirit of comment 21, am I right, igel?
Comment 23 Cedric Sodhi 2013-02-26 19:55:38 UTC
*** Bug 459344 has been marked as a duplicate of this bug. ***
Comment 24 Cedric Sodhi 2013-02-26 20:00:01 UTC
In fact, continuing the line of thought, I think the current --autounmask-write option is a bit over the top.

Especially over the last year I've witnessed a slight tendendy to bloat in Portage. I would like to remind all portage developers that, while convenience is good, it's often not desierable to put it all into one tool.

Portage's job is dependency resolution (which is precisely what this bug concerns) and installation.

Both, overly verbose information and "user information" and command line switches adressing the former are beyond portage's realm and should be kept well outside its specification!
Comment 25 igel 2013-02-28 20:57:02 UTC
(In reply to comment #22)
> Bug 459344 was closed as a duplicate of #458464 which says, quote "no way to
> JUST DAMN INSTALL a package".
> 
> I take the liberty to change the reference to the bug here, for it seems to
> have higher resemblance.
> 
> I think that goes in the spirit of comment 21, am I right, igel?
Right, you're describing the problem quite well in Bug 459344.
Comment 26 Cedric Sodhi 2013-03-05 17:16:19 UTC
Zac, please confirm that you understand the issue correctly. The manner in which you throw those bugs into one pot of "conflict resolution" makes me doubt that you're actually aware of this' (and Bug 459344's) intention.

To make it absolutely clear:

There is no ambiguity in the requirement, nor does it require any kind of resolution beyond what is already taking place.

The *required* USE-Flags are automatically applied on top of profile, make.conf, package.use and environment and if this *leads to* conflicts, they are not resolved.

I ask you to confirm your correct understanding of this issue.
Comment 27 Cedric Sodhi 2013-03-05 17:24:29 UTC
PS: This is much like, if not exactly like normal dependency resolution. Note that USE-Flag resolution IS IN FACT dependency resolution. The plain notion of "figuring out which packages to install" of other package managers does not apply to portage.

The correct definition of dependency resolution on Gentoo is

"Figuring out WHICH packages to install HOW (i.e. USE-Flags)"

Portage currently correctly figures out the WHICH part.

All that is required is integrate the HOW part - which follows the exact same logic as the WHICH part.

It's not yet there? <-> The USE-Flag is not what is needed?
Can it be installed without conflict? <-> Can the USE-Flag be changed without conflict?

This is actually trivial, if planted correctly in the already existing resolver.
Comment 28 Zac Medico gentoo-dev 2013-06-04 21:39:01 UTC
*** Bug 472298 has been marked as a duplicate of this bug. ***
Comment 29 Zac Medico gentoo-dev 2013-08-01 22:30:16 UTC
(In reply to Cedric from comment #26)
> I ask you to confirm your correct understanding of this issue.

Yes I think I understand, and I still stand by my decision to mark your bug as a duplicate of this one.

(In reply to Cedric from comment #27)
> This is actually trivial, if planted correctly in the already existing
> resolver.

A patch would be welcome.
Comment 30 Malte E. 2013-10-16 19:20:35 UTC
I would donate to the person who implements this. I'm a student, so it won't be much, but I may not be the only one.
Comment 31 Zac Medico gentoo-dev 2015-03-21 21:36:18 UTC
*** Bug 543994 has been marked as a duplicate of this bug. ***
Comment 32 haarp 2015-03-29 17:01:32 UTC
Now that abi_x86 has become stable, this feature would be extremely useful! :)
Comment 33 Zac Medico gentoo-dev 2016-06-05 18:01:54 UTC
*** Bug 584430 has been marked as a duplicate of this bug. ***
Comment 34 Zac Medico gentoo-dev 2016-07-03 19:25:59 UTC
The --autounmask-continue option introduced in bug 582624 brings us a little closer, since it fully automates configuration updates.
Comment 35 Richard Freeman gentoo-dev 2016-07-04 10:49:06 UTC
(In reply to Zac Medico from comment #34)
> The --autounmask-continue option introduced in bug 582624 brings us a little
> closer, since it fully automates configuration updates.

A little, but ideally this should work without modifying anything in /etc, as with regular dependency resolution. Imagine the long-term effects of an option that automatically adds every dependency that gets installed to @world...
Comment 36 Simon 2016-08-28 12:17:50 UTC
Hi i had these problems:

>>>
The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by www-client/chromium-52.0.2743.116::gentoo
# required by chromium (argument)
>=dev-libs/libxml2-2.9.4 icu
<<<

1. Installing chromium i needed icu for libxml2 so i did autounmask-write and dispatch-conf and the ">=dev-libs/libxml2-2.9.4 icu" was added, but it was added to the package.use/wine file, not to my package.use/packages how is the file chosen to which the USE-Flag is written? I think that could be more sophisicasted by using a fixed name.

>>>
--- /etc/portage/package.use/wine       2016-08-25 23:01:44.826924812 +0200
+++ /etc/portage/package.use/._cfg0000_wine     2016-08-28 10:31:53.293507106 +0200
@@ -404,3 +404,6 @@
 # required by @selected
 # required by @world (argument)
 >=dev-libs/nettle-3.2-r1 abi_x86_32
+# required by www-client/chromium-52.0.2743.116::gentoo
+# required by chromium (argument)
+>=dev-libs/libxml2-2.9.4 icu
<<<

Then:
>>>
dev-libs/libxml2:2

  (dev-libs/libxml2-2.9.4:2/2::gentoo, ebuild scheduled for merge) conflicts with
    dev-libs/libxml2:2[-icu,abi_x86_32(-),abi_x86_64(-)] required by (dev-qt/qtwebkit-4.8.6-r1:4/4::gentoo, installed)
                       ^^^^                             


The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by www-client/chromium-52.0.2743.116::gentoo
# required by chromium (argument)
=dev-libs/libxml2-2.9.3 icu
<<<

2. Why didn't see emerge before, that it needs libxml-2.9.3 as well and not just libxml-2.9.4?

3. I think emerge should not write qtwebkit here, but qtwebkit[-icu] or such to show that the conflict comes from a missing use flag in qtwebkit, not from qtwebkit itself.

4. I think emerge should recognize, that this conflict can be solved by writing the icu USE Flag for qtwebkit as well and queue qtwebkit to be re-emerged. So --autounmask-write et alii could write "libxml icu" AND "qtwebkit icu" and queue qtwebkit with the new useflag to automatically solve this problem.


I think this were to much problems for just emerging chromium, hope emerge will get better to resolve those conflicts automatically, so i just say emerge chromium and it shows me what needs to be changed or reemerged at once.


Thanks.
Comment 37 Zac Medico gentoo-dev 2016-11-08 16:38:22 UTC
*** Bug 599208 has been marked as a duplicate of this bug. ***
Comment 38 Michael Mair-Keimberger (iamnr3) 2018-01-09 20:33:49 UTC
Hi,

Every now and then i'm looking at my package.use file and try to get some order in it. Honestly, this file would look alot nicer and cleaner with this feature :)
Any progress on this bug? It would be really a valuable feature i think :)
Comment 39 Zac Medico gentoo-dev 2018-03-24 18:20:53 UTC
Currently, the --autounmask-continue option must write package.use changes to disk and then reload the configuration from disk. We can avoid write/reload requirement simply by updating the UseManager _pusedict attribute in memory:

https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/package/ebuild/_config/UseManager.py?h=portage-2.3.24#n103