OK, I (now) see... http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=7ab4d5722a828167dd1bf946b26cfa80808f59fc But, there's no mention of FEATURES=fixpackages removal in the changelog (which I faithfully scan at each portage update, checking bugs as I think it pertains to me), and no ewarn about it. All I get is this whenever I try to do anything with emerge: FEATURES variable contains unknown value(s): fixpackages And... there's no clue as to what I should replace it with! Luckily for me I *DO* reach the changelogs, and saw the mention of the new --dynamic-deps option and read the emerge manpage option on it, so putting two and two together I figured it must be related and reasonably quickly found the above git commit. But that still leaves me with little clue as to whether the --dynamic-deps=y default fully replaces FEATURES=fixpackages, or whether I now need to run fixpackages manually as part of my portage and overlay update scripts, or whether since it's actually two actions one might still be automatic but I need to script the other one... or what? So please, add an ewarn or something explaining the issue, at least for people that have FEATURES=fixpackages in their make.conf (or files it includes, as is the case here) and thus weren't simply depending on the global setting. And preferably, put an ewarn explanation on your list for any time you change options, features, etc, too. A simple link to a bug with sufficient discussion (or mention of the manpage and search term to use therein) generally suffices for me, tho it might not for some, but even that was lacking, here, possibly because this was a removal, not an addition, and was a follow-on to something else, not a primary development in its own right. Meanwhile, an answer here would be nice, too, so I don't have to worry about my next scripted esync leaving unfixed cruft behind because a feature was yanked and I didn't know what to add to my sync-script to replace it. Finally, while doing the pre-file bug search, I came across bug #243380 from 2008, related to fixpackages documentation, that's still open. I'd guess it needs reexamined in light of the current changes, too, and that it shouldn't be too difficult to put that bug to bed at about the same time too, since you're already dealing with fixpackages and the related user documentation. =:^) As always, thanks for all the hard work on such a core-to-gentoo package. =:^) Duncan
*** Bug 386893 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Meanwhile, an answer here would be nice, too, so I don't have to worry about my > next scripted esync leaving unfixed cruft behind because a feature was yanked > and I didn't know what to add to my sync-script to replace it. Really, what happened was that FEATURES=fixpackages became unconditionally enabled. Your make.conf setting that triggers the warning message has not been needed since FEATURES=fixpackages was enabled by default almost 3 years ago: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=dc3dcf67b7f26e4619f7bdb0987364963834aab2
(In reply to comment #2) > Really, what happened was that FEATURES=fixpackages became unconditionally > enabled. Your make.conf setting that triggers the warning message has not been > needed since FEATURES=fixpackages was enabled by default almost 3 years ago Thanks. I figured that, but wasn't sure, and I guess it's understandable that I'm a bit worried when something as critical as portage starts yelling at me about a feature that has been there for awhile. =:^\ As for default features, some time ago I took the whole list and specifically entered them, normal or negated, in make.conf. Now I don't have to wonder where something's set, and if it IS a new feature not yet in make.conf, I KNOW it's new and that I've not looked at it in detail yet. Plus that way I get warnings when the feature changes and can followup to be sure that I know how portage's behavior may be changing as a result. =:^) I do much the same thing with many of the USE flags but there's more of them and they change rather more regularly, and there's some that simply need set in package.use in any case, so I can't make the same assumptions, there. But it still dramatically simplifies what can otherwise be quite a look thru package default-use and various cascaded profiles to see where the setting comes from. $>>cat /etc/portage/make//features #/etc/portage/make/features # autoconfig?? # fixpackages removed for 2.2.0-alpha67, see emerge --dynamic-deps option # normal FEATURES=" -assume-digests binpkg-logs buildpkg buildsyspkg candy ccache collision-protect -compress-build-logs -digest -distcc distlocks ebuild-locks -fakeroot -fail-clean fixlafiles -force-mirror -getpbinpkg -installsources -keeptemp -keepwork -lmirror metadata-transfer -mirror -multilib-strict news -noauto -noclean -nodoc -noinfo -noman -nostrip -notitles parallel-fetch parallel-install -parse-eapi-ebuild-head -prelink-checksumps -preserve-libs protect-owned -python-trace sandbox -severe sfperms -sign -skiprocheck -split-elog -split-log -splitdebug strict -stricter -suidctl -test -test-fail-continue -unknown-features-filter unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync -webrsync-gpg "
I've put a note in RELEASE-NOTES: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a73ad44e390aa14e8785d90d590f87a5d06e3866
Also applies to latest stable portage -- sys-apps/portage-2.1.10.27? Receiving the same notice there. Just found it on several of our production servers running stable -- guess I need to update puppet config files for make.conf to remove fixpackages from features line for all our boxes going forward.
(In reply to comment #5) > Also applies to latest stable portage -- sys-apps/portage-2.1.10.27? Right.
(In reply to comment #4) > I've put a note in RELEASE-NOTES: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a73ad44e390aa14e8785d90d590f87a5d06e3866 This is in 2.1.10.28 and 2.2.0_alpha68.
*** Bug 395459 has been marked as a duplicate of this bug. ***
