Re: [gentoo-dev] Revisions for USE flag changes
On pią, 2017-08-11 at 19:50 -0400, Michael Orlitzky wrote: > We have a pull request for the devmanual that will update the revision > documentation; namely, when to create a new one: > > https://github.com/gentoo/devmanual.gentoo.org/pull/67 > > The comments bring up an issue that I think can benefit from some > hindsight. Specifically, the PR says that it's OK to change IUSE without > creating a revision, because users can use --changed-use to catch it. > My immediate objection to that was that --changed-use is specific to > Portage, but let's reflect on the status quo. > > > == The situation now == > > 1 We tell everyone to update with either --newuse or --changed-use. > > 2 Developers change IUSE without new revisions. > > 3 To facilitate (1) and (2), Portage has the --changed-use and > --newuse flags. Paludis has a family of "--keep" options to avoid > reinstallation, e.g. --keep=if-same-metadata. And pkgcore has its > own (different) --newuse flag. > > 4 There is no specification for the features in (3), and each package > manager has taken a different approach. > > > The end result is that Portage users do see the changes made to IUSE > without a revision, but at a cost: > > * They have to pass the "required" --changed-use or --newuse flags to > every command. > > * The same cannot be said for users of other package managers. > > * Lots of PM code exists to handle this stuff. > > * Our documentation needs to describe the above (relatively) > complicated situation. > > > And with one notable benefit: > > * We don't need to rename the ebuild to change IUSE, and in theory we > can control when rebuilds happen. > > > > == New revisions for USE flag changes == > > I suggest that in hindsight, we can do better. Suppose we require a new > revision for every change to IUSE. Then, > > * We can delete all of the PM code for --changed-use and --newuse and > friends. > > * The documentation becomes much simpler: revbump if IUSE changes. > > * Users can omit --newuse and --changed-use from their lives. > > * All package managers now handle IUSE changes properly. > > * emerge runs a bit faster. > > This has none of the downsides of the current approach. Of course, it > lacks that one benefit -- that you don't have to rename the ebuild when > you change IUSE. Now I'll try to convince you that the rename and > associated rebuilds aren't that big of a deal. > > > Q. But what about the rebuilds? > > For most packages, the rebuilds simply don't matter. Unless you're > the maintainer of libreoffice, firefox, chromium, etc. -- just do the > revision and forget about the (quick) rebuilds. > > We tell everyone to use --changed-use and --newuse if they want > things to work, so they were probably going to rebuild anyway. > > > Q. But what if I maintain firefox, and I need to change IUSE? > > If the IUSE change isn't important, just make the new revision in a > branch and wait to commit it later when there are more changes > piled up. If it is important (like if its default value changes > RDEPEND), then it would have required a revision anyway. > > > Q. But I work on a team, and we can't all work in different branches. > > If you work on a massive package and if you're collaborating with > others regularly, you can commit the new ebuild masked. This is > annoying, but is an extremely rare combination of circumstances. > > > == tl;dr == > > We would be better off with respect to IUSE changes and revisions if we > deleted the --changed-use and --newuse flags right now, and just > required developers to revbump when changing IUSE. > > Package managers get simpler, documentation gets simpler, the user > interface gets simpler, and behavior becomes more uniform and predictable. > > Please let me know what you think. > Please provide some examples of recent in-place USE changes that benefit from revbumps. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New SYMLINK_LIB=no migration tool for review
On pią, 2017-08-11 at 16:56 -0700, Gerogy Yakovlev wrote:
> Hi,
>
> I was able to test this one a bit.
> The test subjects were:
> ~amd64/openrc/desktop system which I was going to wipe anyway.
> amd64/openrc latest snapshot, updated to ~amd64 with boostrtap.sh
>
> for the latter symlink migration was done before bootstrapping,
Thanks a lot for testing.
> So far I found 3 issues so far:
>
> 1) kernel modules. modprobe looks into /lib/modules/$(uname -r), but
> after running the tool they end up in /lib64/modules.
Hmm, my test chroot did not have Linux modules. I'm going to test that.
I suspect it's because 'modules' is not owned by any package on your
system, so it doesn't touch it at all.
I need to rethink that. Maybe it'd be better to just move everything
unowned to /lib.
> 2) app-eselect/eselect-mesa has some hardcoded paths:
> MESA_CONF_DIR="${EROOT}/usr/share/mesa"
> MESA_DIR_64="${EROOT}/usr/lib/mesa"
> DRI_DIR_64="${EROOT}/usr/lib/dri"
> MESA_DIR_32="${EROOT}/usr/lib32/mesa"
> DRI_DIR_32="${EROOT}/usr/lib32/dri"
> that leads to many funny breakages.
https://bugs.gentoo.org/486712
>
> 3) and minor one, sys-boot/refind will fails to build, because it looks
> for 64bit libs in lib.
Could you file a bug with a build log for it? Leave a note that it's on
SYMLINK_LIB=no system.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Revisions for USE flag changes
On 12/08/2017 03:11, Brian Evans wrote: > --changed-use (-U) >Tells emerge to include installed packages where USE flags have >changed since installation. This option also implies the >--selective option. Unlike --newuse, the --changed-use option >does not trigger reinstallation when flags that the user has not >enabled are added or removed. > > The option is the same as --newuse except it ignores functionality that > you suggest to remove. You could certainly deprecate one option or the > other if they became the same. But the core functionality of > system-wide USE changes (by profile or user), needs to be scanned somehow. +1 There are use-cases for --changed-use / --newuse other than changed IUSE. I find it useful to easily rebuild affected packages when changing USE flags in make.conf. If the flags were removed, would we have a good alternative? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Revisions for USE flag changes
On 08/12/2017 03:03 AM, Michał Górny wrote: > > Please provide some examples of recent in-place USE changes that benefit > from revbumps. > There is no single example. Things only get simpler if *all* USE changes come with a new revision.
Re: [gentoo-dev] Revisions for USE flag changes
On 08/12/2017 04:39 AM, Paweł Hajdan, Jr. wrote: >> >> The option is the same as --newuse except it ignores functionality that >> you suggest to remove. You could certainly deprecate one option or the >> other if they became the same. But the core functionality of >> system-wide USE changes (by profile or user), needs to be scanned somehow. > > +1 > > There are use-cases for --changed-use / --newuse other than changed IUSE. > > I find it useful to easily rebuild affected packages when changing USE > flags in make.conf. If the flags were removed, would we have a good > alternative? > I simply overlooked the global USE change in make.conf because IMO it's a nonsense operation. But people do it, and we support it, so for the sake of argument forget I mentioned removing --newuse. The --changed-use flag would be redundant, though (it would do the same thing as --newuse).
Re: [gentoo-dev] Revisions for USE flag changes
On 08/12/2017 11:57 AM, Michael Orlitzky wrote: > There is no single example. Things only get simpler if *all* USE changes > come with a new revision. IMO every significant(*) change should yield into a revision bump. (*) == comments and echo arguments changes are not significantly, all others however are -- Toralf PGP 23217DA7 9B888F45 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Revisions for USE flag changes
On 08/12/2017 12:22 AM, Michael Palimaka wrote: > >> Q. But what if I maintain firefox, and I need to change IUSE? >> >> If the IUSE change isn't important, just make the new revision in a >> branch and wait to commit it later when there are more changes >> piled up. If it is important (like if its default value changes >> RDEPEND), then it would have required a revision anyway. > > Please stop trying to force workflows on people. Using that same logic, > I can make the IUSE change in-place and it would be propagated in the > next version bump. > I'm not trying to force anything on anyone, I'm just asking for feedback. If it turns out to be a stupid idea, then so be it. If it's understood that you can make IUSE changes but that they'll only be propagated on the next version bump, then there would be no problem. But we're about to document a policy that says it's OK to do things that wouldn't normally be OK, because --changed-use is there to save us: The examples of changes that can be done without a revision bump are: ... * adding a new USE flag or removing an existing one (since change in USE flags is going to trigger --changed-use rebuild), If developers operate under that assumption and if you don't use --changed-use, you're going to run into problems eventually. >> * emerge runs a bit faster. > > Why will it run faster? The developer now indicates that IUSE has changed, so portage doesn't have to figure it out on its own.
Re: [gentoo-dev] Revisions for USE flag changes
On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky wrote: > On 08/12/2017 03:03 AM, Michał Górny wrote: >> >> Please provide some examples of recent in-place USE changes that benefit >> from revbumps. >> > > There is no single example. Things only get simpler if *all* USE changes > come with a new revision. > My gut feeling is that the change you want is probably a good thing, but it will never happen if you can't provide a single example of something bad happening due to the lack of a revbump. The easy counter-argument to your suggestion is "if it ain't broke, don't fix it." As others have pointed out, the portage flags are useful even if we make this change, so they're not going away. Also, I don't see any portage maintainers saying that they want this change, or that they'll remove any code if this change is made. The only potential benefit I see is QA. However, I've been running with --changed-use for eons (and was running with --newuse before that) so I couldn't tell you what happens in practice when you don't use those settings. This policy change would make my life easier, because for big packages it would encourage maintainers to not make IUSE changes until they do revbumps, which would save me a build. I'm running on relatively old hardware at this point so these rebuilds actually do cost me quite a bit of time. I'm not sure that not using --changed-use is a great option though as it will make it that much harder to keep things consistent when I do modify my package.use/make.conf. -- Rich
Re: [gentoo-dev] Re: Revisions for USE flag changes
On Sat, Aug 12, 2017 at 12:22 AM, Michael Palimaka wrote: > On 08/12/2017 09:50 AM, Michael Orlitzky wrote: >> Q. But what about the rebuilds? >> >> For most packages, the rebuilds simply don't matter. Unless you're >> the maintainer of libreoffice, firefox, chromium, etc. -- just do the >> revision and forget about the (quick) rebuilds. > > I really wish people would stop trotting out this false argument. Not > everyone has the latest and greatest hardware. Rebuilds have a real cost > to end users and as such we should use them wisely. > Agree, but maintainers would have the option to just not change IUSE at all until the next time they would revbump anyway. That saves rebuilds for those using --changed-use today. I'm not convinced that it is actually that easy for people to avoid --changed-use, and if they are using it then they're going to potentially get exposed to these rebuilds when IUSE changes. -- Rich
[gentoo-dev] Re: Revisions for USE flag changes
On 08/12/2017 08:16 PM, Michael Orlitzky wrote: > On 08/12/2017 12:22 AM, Michael Palimaka wrote: >> >>> Q. But what if I maintain firefox, and I need to change IUSE? >>> >>> If the IUSE change isn't important, just make the new revision in a >>> branch and wait to commit it later when there are more changes >>> piled up. If it is important (like if its default value changes >>> RDEPEND), then it would have required a revision anyway. >> >> Please stop trying to force workflows on people. Using that same logic, >> I can make the IUSE change in-place and it would be propagated in the >> next version bump. >> > > I'm not trying to force anything on anyone, I'm just asking for > feedback. If it turns out to be a stupid idea, then so be it. > > If it's understood that you can make IUSE changes but that they'll only > be propagated on the next version bump, then there would be no problem. > But we're about to document a policy that says it's OK to do things that > wouldn't normally be OK, because --changed-use is there to save us: > > The examples of changes that can be done without a revision bump are: > > ... > > * adding a new USE flag or removing an existing one (since change > in USE flags is going to trigger --changed-use rebuild), > > If developers operate under that assumption and if you don't use > --changed-use, you're going to run into problems eventually. --changed-use is an optional flag and portage works just as well without it. Please provide examples of such problems. > > >>> * emerge runs a bit faster. >> >> Why will it run faster? > > The developer now indicates that IUSE has changed, so portage doesn't > have to figure it out on its own. Please provide some numbers to back up this claim. Even if we assume portage will run faster because we can remove --changed-use (which we can't, because as pointed out in other posts we still need this flag), surely any time savings gained there will be lost by pointless rebuilds?
[gentoo-dev] Re: Revisions for USE flag changes
On 08/12/2017 08:29 PM, Rich Freeman wrote: > On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky wrote: >> On 08/12/2017 03:03 AM, Michał Górny wrote: >>> >>> Please provide some examples of recent in-place USE changes that benefit >>> from revbumps. >>> >> >> There is no single example. Things only get simpler if *all* USE changes >> come with a new revision. >> > This policy change would make my life easier, because for big packages > it would encourage maintainers to not make IUSE changes until they do > revbumps, which would save me a build. I'm running on relatively old > hardware at this point so these rebuilds actually do cost me quite a > bit of time. I'm not sure that not using --changed-use is a great > option though as it will make it that much harder to keep things > consistent when I do modify my package.use/make.conf. > At least now you have the option to run without --changed-use if you want. If inline IUSE changes are completely banned, you will definitely see more pointless rebuilds on your old hardware. In my experience most developers make a change when there's a change to be made, and don't "save up" changes until some arbitrary delta is reached. We've already an increase in revbumps like this in other areas where inline changes are being discouraged.
Re: [gentoo-dev] Re: Revisions for USE flag changes
On Sat, Aug 12, 2017 at 7:05 AM, Michael Palimaka wrote: > On 08/12/2017 08:29 PM, Rich Freeman wrote: >> On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky wrote: >>> On 08/12/2017 03:03 AM, Michał Górny wrote: Please provide some examples of recent in-place USE changes that benefit from revbumps. >>> >>> There is no single example. Things only get simpler if *all* USE changes >>> come with a new revision. >>> >> This policy change would make my life easier, because for big packages >> it would encourage maintainers to not make IUSE changes until they do >> revbumps, which would save me a build. I'm running on relatively old >> hardware at this point so these rebuilds actually do cost me quite a >> bit of time. I'm not sure that not using --changed-use is a great >> option though as it will make it that much harder to keep things >> consistent when I do modify my package.use/make.conf. >> > > At least now you have the option to run without --changed-use if you > want. If inline IUSE changes are completely banned, you will definitely > see more pointless rebuilds on your old hardware. True, since we now have --changed-use (I think this is a relatively recent portage feature - before there was only --newuse). Obviously if I stopped using --changed-use then my installed configuration would drift out of sync with the settings in /etc/portage. I'm not sure that this causes any other issues in this case - there certainly have been issues historically in these situations but I think most of them have been eliminated. Changed dependencies can definitely cause problems, but I'm less certain that changed IUSE does. > In my experience most > developers make a change when there's a change to be made, and don't > "save up" changes until some arbitrary delta is reached. We've already > an increase in revbumps like this in other areas where inline changes > are being discouraged. > I imagine that such practices vary. I know I personally tend to save up minor changes for major revisions to reduce the need for testing. Ultimately though I think the real question is whether not revbumping has the potential to break things. I does for dependency changes which is why that policy change was made (and I still run with --changed-deps anyway because I don't trust devs to not mess this up). I think we do need to have more clear evidence that IUSE changes break things before we should consider requiring revbumps for this. It would be nice if big packages waited for revbumps to make IUSE changes, but honestly the occassional chromium rebuild doesn't bother me that much. Most of it happens with cron anyway. -- Rich
Re: [gentoo-dev] Revisions for USE flag changes
On 08/12/2017 06:29 AM, Rich Freeman wrote: > > My gut feeling is that the change you want is probably a good thing, > but it will never happen if you can't provide a single example of > something bad happening due to the lack of a revbump. There's an unfixed security vulnerability with USE=foo, so we drop the flag temporarily. Users who had USE=foo enabled will keep the vulnerable code installed until they update with --changed-use or --newuse. Even with the devmanual improvements, the advice we give is conflicting: * If you fix an important runtime issue, do a revbump. * If you drop a USE flag, don't do a revbump. What if you fix a runtime issue by dropping a flag? It's more confusing than it has to be: the USE flag exception interacts weirdly with all the other rules.
Re: [gentoo-dev] Changing PMS to Portage Manager Specification
While the PMS perhaps hasn't been an unequivocal success, it's still a good effort with some success. I would be disappointed to see the proposed change, and view it as a bad sign for Gentoo. -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing PMS to Portage Manager Specification
On Sat, Aug 12, 2017 at 9:50 AM, Alexander Berntsen wrote: > While the PMS perhaps hasn't been an unequivocal success, it's still a > good effort with some success. I would be disappointed to see the > proposed change, and view it as a bad sign for Gentoo. > Also, how many Portages are there that need to be managed with a "Portage Manager"?
Re: [gentoo-dev] New SYMLINK_LIB=no migration tool for review
On śro, 2017-08-02 at 17:58 +0200, Michał Górny wrote:
> Hi, everyone.
>
> I've finally gotten around to writing a new tool for migrating amd64
> systems to SYMLINK_LIB=no layout [1]. I've put it in symlink-lib-
> migration [2] repository along with a README. Please review it and give
> it more testing.
I've pushed two important fixes now:
a. The tool now processes unowned files as well -- *.{a,la,so} are left
in lib64 (i.e. the symlinks created by db.eclass and alikes) while
everything else goes into lib.
b. I've fixed cleanup phase to also remove top-level files
and directories that were moved out of lib64. Also, I've fixed it not to
complain about trying to remove non-empty directories.
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=506276
> [2]:https://github.com/mgorny/symlink-lib-migration
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] out-of-source.eclass: A new eclass to help with out-of-source builds
The out-of-source.eclass is a simple multilib-minimal-style wrapper
to perform out of source builds of autotools (and other) packages. It is
mostly derived from the function served in the past by autotools-utils
since a number of developers found it useful. However, in order to avoid
the mistakes of autotools-utils, it is meant to be focused on a single
feature and have a better API.
This eclass has two use cases:
1. Ensuring that packages are tested with out-of-source builds.
2. Improving consistency between multilib and non-multilib packages.
// NB: I've even considered naming the phases multilib_*() to make
// switching to multilib even easier.
In the most basic form, it just redefines the phases from src_configure()
to src_install() with out-of-source wrappers. However, each phase can
be overriden using my_src_*() sub-phase that is run inside build dir
(alike multilib_src_*() in multilib-minimal). There is also
my_src_install_all() for the trailing source-dir actions.
// I'm wondering whether ECONF_SOURCE should be declared unconditionally
// as it is now in the patch, or if it should only be included
// in the default and required to be specified in my_src_configure()
// when redefined. FWICS, multilib-minimal currently requires it
// explicitly specified all the time.
---
eclass/out-of-source.eclass | 123
1 file changed, 123 insertions(+)
create mode 100644 eclass/out-of-source.eclass
diff --git a/eclass/out-of-source.eclass b/eclass/out-of-source.eclass
new file mode 100644
index ..e19256426882
--- /dev/null
+++ b/eclass/out-of-source.eclass
@@ -0,0 +1,123 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: out-of-source.eclass
+# @MAINTAINER:
+# Michał Górny
+# @BLURB: convenient wrapper to build autotools packages out-of-source
+# @DESCRIPTION:
+# This eclass provides a minimalistic wrapper interface to easily
+# build autotools (and alike) packages out-of-source. It is meant
+# to resemble the interface used by multilib-minimal without actually
+# requiring the package to be multilib.
+#
+# For the simplest ebuilds, it is enough to inherit the eclass
+# and the new phase functions will automatically build the package
+# out-of-source. If you need to redefine one of the default phases
+# between src_configure() and src_install(), you need to define
+# the sub-phases: my_src_configure(), my_src_compile(), my_src_test()
+# and my_src_install() instead that will be run inside the build
+# directory. Additionally, my_src_install_all() is provided to perform
+# doc-install and other common tasks done in source directory.
+#
+# Example use:
+# @CODE
+# inherit out-of-source
+#
+# my_src_configure() {
+# econf \
+# --disable-static
+# }
+# @CODE
+
+case ${EAPI} in
+ 6);;
+ *) die "EAPI ${EAPI:-0} unsupported (too old)";;
+esac
+
+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
+
+if [[ ! ${_OUT_OF_SOURCE_ECLASS} ]]; then
+
+# @FUNCTION: out-of-source_src_configure
+# @DESCRIPTION:
+# The default src_configure() implementation establishes a BUILD_DIR,
+# sets ECONF_SOURCE to the current directory (usually S), and runs
+# my_src_configure() (or the default) inside it.
+out-of-source_src_configure() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ # set some BUILD_DIR if we don't have one yet
+ : "${BUILD_DIR:=${WORKDIR}/${P}_build}"
+ local ECONF_SOURCE=${PWD}
+
+ mkdir -p "${BUILD_DIR}" || die
+ pushd "${BUILD_DIR}" >/dev/null || die
+ if declare -f my_src_configure >/dev/null ; then
+ my_src_configure
+ else
+ default_src_configure
+ fi
+ popd >/dev/null || die
+}
+
+# @FUNCTION: out-of-source_src_compile
+# @DESCRIPTION:
+# The default src_compile() implementation runs my_src_compile()
+# (or the default) inside the build directory.
+out-of-source_src_compile() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ pushd "${BUILD_DIR}" >/dev/null || die
+ if declare -f my_src_compile >/dev/null ; then
+ my_src_compile
+ else
+ default_src_compile
+ fi
+ popd >/dev/null || die
+}
+
+# @FUNCTION: out-of-source_src_test
+# @DESCRIPTION:
+# The default src_test() implementation runs my_src_test()
+# (or the default) inside the build directory.
+out-of-source_src_test() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ pushd "${BUILD_DIR}" >/dev/null || die
+ if declare -f my_src_test >/dev/null ; then
+ my_src_test
+ else
+ default_src_test
+ fi
+ popd >/dev/null || die
+}
+
+# @FUNCTION: out-of-source_src_install
+# @DESCRIPTION:
+# The default src_install() implementation runs my_src_install()
+# (or the 'make install' part of the default) inside the build directory,
+# followed by a call to my_src_install_all() (or 'einstalldocs'
[gentoo-dev] Re: Revisions for USE flag changes
Michael Orlitzky posted on Sat, 12 Aug 2017 10:14:18 -0400 as excerpted: > On 08/12/2017 06:29 AM, Rich Freeman wrote: >> >> My gut feeling is that the change you want is probably a good thing, >> but it will never happen if you can't provide a single example of >> something bad happening due to the lack of a revbump. > > There's an unfixed security vulnerability with USE=foo, so we drop the > flag temporarily. Users who had USE=foo enabled will keep the vulnerable > code installed until they update with --changed-use or --newuse. > > Even with the devmanual improvements, the advice we give is conflicting: > > * If you fix an important runtime issue, do a revbump. > > * If you drop a USE flag, don't do a revbump. > > What if you fix a runtime issue by dropping a flag? It's more confusing > than it has to be: the USE flag exception interacts weirdly with all the > other rules. Bad example as it's a security vuln, which requires masking/removing vulnerable versions, which will require a version bump in ordered to prevent downgrades if it was the latest visible for a (stable or ~arch) keyword. So the version bump is effectively mandatory due to security overrides in any case, and that it was fixed by a temporary USE flag drop doesn't change things at all. If that security-override isn't explicit in current documentation, that'd be the bug, not the fact that use-flag drops don't on their own require a version-bump. -- 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: Revisions for USE flag changes
Michael Orlitzky posted on Sat, 12 Aug 2017 05:58:41 -0400 as excerpted: > On 08/12/2017 04:39 AM, Paweł Hajdan, Jr. wrote: > >> There are use-cases for --changed-use / --newuse other than changed >> IUSE. >> >> I find it useful to easily rebuild affected packages when changing USE >> flags in make.conf. If the flags were removed, would we have a good >> alternative? >> > I simply overlooked the global USE change in make.conf because IMO it's > a nonsense operation ?? How so? Are you arguing that deciding to system-wide switch to/from pulseaudio, systemd, or gstreamer is nonsense? If so, I suspect many gentooers including myself strongly disagree. If not, I'd be interested in what you propose as an alternative to changing the appropriate USE flag systemwide, for what is after all a systemwide change. Just seems to me an extremely surprising and unexpected argument, so I'd like to understand more of the reasoning behind it. I'll very likely learn something, as invariably the answer to questions I find myself compelled to ask due to what appears to me a transparently obvious different answer, reveal an angle I hadn't previously considered, sometimes changing my mind entirely. =:^) -- 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] Revisions for USE flag changes
On Sat, 2017-08-12 at 05:58 -0400, Michael Orlitzky wrote: > > I simply overlooked the global USE change in make.conf because IMO > it's > a nonsense operation. This also happens routinely as new python and ruby versions are marked stable, not via make.conf, but by removing their use.stable.mask. Hans signature.asc Description: This is a digitally signed message part
