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
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.
Ah, OK, thanks a lot :-)
(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.
(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?
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.
(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?
(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.
(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.
Is there any progress on this? Just wondering, I'm not intending to annoy you guys ;)
(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.
*** Bug 294162 has been marked as a duplicate of this bug. ***
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
(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
*** Bug 328343 has been marked as a duplicate of this bug. ***
The --autoumask option from bug 280097 can automatically generate package.use settings for you.
*** Bug 256519 has been marked as a duplicate of this bug. ***
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...
(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).
*** Bug 454270 has been marked as a duplicate of this bug. ***
*** Bug 454580 has been marked as a duplicate of this bug. ***
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.
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?
*** Bug 459344 has been marked as a duplicate of this bug. ***
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!
(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.
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.
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.
*** Bug 472298 has been marked as a duplicate of this bug. ***
(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.
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.
*** Bug 543994 has been marked as a duplicate of this bug. ***
Now that abi_x86 has become stable, this feature would be extremely useful! :)
*** Bug 584430 has been marked as a duplicate of this bug. ***
The --autounmask-continue option introduced in bug 582624 brings us a little closer, since it fully automates configuration updates.
(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...
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.
*** Bug 599208 has been marked as a duplicate of this bug. ***
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 :)
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
