Re: [gentoo-dev] useflag policies
On 4 August 2015 at 22:56, Ian Stakenvicius a...@gentoo.org wrote: Are there any cases where things actually break if a package has both flags enabled? IE, is three a package with IUSE=qt4 qt5 that when both flags are enabled would build for qt5 only, and happens to be a dependency atom of something else that needs it to have qt4 support? That to me is the only case where a REQUIRED_USE needs to be set on a package. I'm not aware we have such a package, but I may be overlooking something. Either way, I think it is a dangerous road to go down that way. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 5 August 2015 at 03:09, Davide Pesavento p...@gentoo.org wrote: On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot yng...@gentoo.org wrote: On 4 August 2015 at 04:20, Rich Freeman ri...@gentoo.org wrote: [...] Gentoo should be the best of both worlds. We should give users the power to tweak things, but we shouldn't force them to play with config files all day long just to have a functional system. If users want to care we let them care instead of telling them don't touch like most other distros, but if they don't care we still provide reasonable defaults. And that is exactly what we do. The kde profile enables qt4, the plasma profile enables qt5, the other profiles have no qt* useflags enabled. These are reasonable defaults. As tetromino pointed out, this is very far from the real current situation. Indeed, I was wrong here. We will need another solution. Of course some users will proceed to enable both qt4 and qt5 globally in their make.conf, but I don't think it is unreasonable to expect them to then deal with adding exceptions to package.use for those packages where exactly-one-of is required. In my opinion, this is the way Gentoo has always worked, and we should simply recommend users to only set one of the qt* useflags as globally enabled, if they want to prevent such micro-management. Hiding the qt4 option is in my opinion the wrong solution around people complaining after they have consciously enabled both flags. If this is not acceptable (or absolutely unusable as one dev put it), then we need a proper solution, which a) will not hide the qt4 option, and b) will prevent triggering required_use blockage by choosing qt5 over qt4 in case both are enabled, while c) informing the user about this. This probably requires new eclass or even EAPI functionality. Please go ahead and design and implement such functionality (a sort of REQUIRED_USE defaults). Something along the lines of PYTHON_TARGETS could work. But personally, I'm happy with REQUIRED_USE. In the meantime, we will apply the policies written in the Qt project wiki page. Except for the one that is wrong. In the meantime, we should stick with the policies adopted at the qt3 to qt4 transition (explicit versioned useflags) and let the user deal with per-package management if they enable both flags. We didn't have REQUIRED_USE at the time of the qt3-qt4 transition, so this point is completely moot. We had something worse. That didn't prevent us from using it tho. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
On Wed, Aug 05, 2015 at 04:50:40AM +, Duncan wrote: Ian Stakenvicius posted on Tue, 04 Aug 2015 17:17:51 -0400 as excerpted: So what you are suggesting here now is that you want to (A) potentially break mounting with the need to externally manage mounts via services in openrc instead of just using /etc/fstab, and (B) also break services if something doesn't start, which is one of the reasons why you wanted to go through with this per-mount service in the first place. My point is that no, we should keep localmount as succeeding even if one of the dependent services fails to mount, *just like it does right now*, *for the same reasons* as it succeeds on failure right now. +1 IMO, localmount must continue to succeed /by/ /default/, even if some mounts fail, because it's basically legacy, and must maintain legacy behavior. Turning it into a wrapper internally is fine, but the overall localmount must still succeed, as too much depends on that behavior as it is. Here's what I'm trying to deal with. Consider what happens if service a still has need localmount and service b has need mount.foo. Mounting a file system twice causes failures the second time it is mounted, so I either have to add special handling in the new mount script for file systems that are already mounted or come up with a way to make sure localmount runs after all instances of the new mount script. The issue with making sure all mount scripts run before localmount would complicate things more for users because they would have to add the mount.foo symlinks to the appropriate runlevels (boot for local file systems and default for network ones). If I did add special handling to the mount script for an already-mounted file system, what should that be -- to ignore it or remount it? I'm tending toward remount. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/15 10:01 AM, William Hubbs wrote: On Wed, Aug 05, 2015 at 04:50:40AM +, Duncan wrote: Ian Stakenvicius posted on Tue, 04 Aug 2015 17:17:51 -0400 as excerpted: So what you are suggesting here now is that you want to (A) potentially break mounting with the need to externally manage mounts via services in openrc instead of just using /etc/fstab, and (B) also break services if something doesn't start, which is one of the reasons why you wanted to go through with this per-mount service in the first place. My point is that no, we should keep localmount as succeeding even if one of the dependent services fails to mount, *just like it does right now*, *for the same reasons* as it succeeds on failure right now. +1 IMO, localmount must continue to succeed /by/ /default/, even if some mounts fail, because it's basically legacy, and must maintain legacy behavior. Turning it into a wrapper internally is fine, but the overall localmount must still succeed, as too much depends on that behavior as it is. Here's what I'm trying to deal with. Consider what happens if service a still has need localmount and service b has need mount.foo. Mounting a file system twice causes failures the second time it is mounted, so I either have to add special handling in the new mount script for file systems that are already mounted or come up with a way to make sure localmount runs after all instances of the new mount script. Yes. I sincerely hope this was always part of the plan??? If localmount is kept as a 'mount -a' then it won't remount anything that's already been mounted, so nothing to worry about there. If it's a wrapper to the individual local mount.*'s then it just has to depend() on them all via a need/want (so that they will be brought in even if they aren't in the runlevel) and/or the mount.*'s need a 'before localmount' so that they're definitely started/attempted first. Am I missing something that makes this harder than it seems? The issue with making sure all mount scripts run before localmount would complicate things more for users because they would have to add the mount.foo symlinks to the appropriate runlevels (boot for local file systems and default for network ones). Likely true as things stand now, which is why I expect major changes would be needed in openrc internals to make it so this is not necessary. At minimum, want dependencies would need to be used so that if mount.foo's don't exist they won't cause depend() failures. (You thought this system was going to let you get away with -not- using 'want' for mounting, didn't you? :) Of course this still doesn't handle how depend() sections will be dynamically generated from /etc/fstab in the first place, nor how the cache will be affected by this; so there's still lots of work to do to sort that out. If I did add special handling to the mount script for an already-mounted file system, what should that be -- to ignore it or remount it? I'm tending toward remount. Well you're already deciding to return success if the mount.foo doesn't actually point to a real mount, so I don't see why this can't be extended to return success if the filesystem is already mounted too. But either way, so long as it works. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXCGyUACgkQAJxUfCtlWe1VngD+P8nVY6FUbYmzcQvRIP7GUi+h Q6V2C+q1yq3Hr1AcqhQBAKGvn790n+XmMiYAbprRFqT4cmWRobEFnhlnPnnQQyuI =jhE8 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
On Wed, Aug 05, 2015 at 10:18:13AM -0400, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/15 10:01 AM, William Hubbs wrote: On Wed, Aug 05, 2015 at 04:50:40AM +, Duncan wrote: Ian Stakenvicius posted on Tue, 04 Aug 2015 17:17:51 -0400 as excerpted: So what you are suggesting here now is that you want to (A) potentially break mounting with the need to externally manage mounts via services in openrc instead of just using /etc/fstab, and (B) also break services if something doesn't start, which is one of the reasons why you wanted to go through with this per-mount service in the first place. My point is that no, we should keep localmount as succeeding even if one of the dependent services fails to mount, *just like it does right now*, *for the same reasons* as it succeeds on failure right now. +1 IMO, localmount must continue to succeed /by/ /default/, even if some mounts fail, because it's basically legacy, and must maintain legacy behavior. Turning it into a wrapper internally is fine, but the overall localmount must still succeed, as too much depends on that behavior as it is. Here's what I'm trying to deal with. Consider what happens if service a still has need localmount and service b has need mount.foo. Mounting a file system twice causes failures the second time it is mounted, so I either have to add special handling in the new mount script for file systems that are already mounted or come up with a way to make sure localmount runs after all instances of the new mount script. Yes. I sincerely hope this was always part of the plan??? If localmount is kept as a 'mount -a' then it won't remount anything that's already been mounted, so nothing to worry about there. If it's a wrapper to the individual local mount.*'s then it just has to depend() on them all via a need/want (so that they will be brought in even if they aren't in the runlevel) and/or the mount.*'s need a 'before localmount' so that they're definitely started/attempted first. Am I missing something that makes this harder than it seems? It isn't localmount that would have the issue, but mount.* because they are lexically after localmount, so you would end up with localmount doing a mount -a then mount.* coming later trying to mount file systems again that were mounted by localmount. The issue with making sure all mount scripts run before localmount would complicate things more for users because they would have to add the mount.foo symlinks to the appropriate runlevels (boot for local file systems and default for network ones). Likely true as things stand now, which is why I expect major changes would be needed in openrc internals to make it so this is not necessary. At minimum, want dependencies would need to be used so that if mount.foo's don't exist they won't cause depend() failures. (You thought this system was going to let you get away with -not- using 'want' for mounting, didn't you? :) Not exactly, I just don't want to use want along with fstab scanning in netmount to try to make netmount start network file system daemons. I never was opposed to the want dependency on its own. Of course this still doesn't handle how depend() sections will be dynamically generated from /etc/fstab in the first place, nor how the cache will be affected by this; so there's still lots of work to do to sort that out. There is no plan to dynamically generate depend() functions. William signature.asc Description: Digital signature
Re: [gentoo-dev] new eclass: golang-vcs-snapshot.eclass for golang vcs snapshots
On Tue, Aug 04, 2015 at 02:19:52PM -0500, William Hubbs wrote:
On Tue, Aug 04, 2015 at 12:17:50PM -0400, Mike Gilbert wrote:
The documentation says you are extracting to ${S}, but the function
actually extracts to ${WORKDIR}/${PN}.
s/PN/P/
I would get rid of the useless destdir variable and replace all
usages with ${S}. Or update the docs.
I got rid of the f and destdir variables and cleaned up the docs; here
is the latest; let me know what you think.
William
This version is now in the tree.
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/15 02:38 AM, Ben de Groot wrote: On 4 August 2015 at 22:56, Ian Stakenvicius a...@gentoo.org wrote: Are there any cases where things actually break if a package has both flags enabled? IE, is three a package with IUSE=qt4 qt5 that when both flags are enabled would build for qt5 only, and happens to be a dependency atom of something else that needs it to have qt4 support? That to me is the only case where a REQUIRED_USE needs to be set on a package. I'm not aware we have such a package, but I may be overlooking something. Either way, I think it is a dangerous road to go down that way. I'm not aware of any either, although I haven't done a comprehensive audit of the tree to find out. I would find it unlikely that any such package exists. The thing is, we're already travelling that road (have been for a long while), and IMO there is very little cost to travelling this road compared to the so-called proper solution of forcing off one flag or the other, ESPECIALLY when we are likely to have both flags default-on soon in the generic desktop profile as was posted earlier. If we do go the REQUIRED_USE=^^ route on packages, then I think it would be best that we change the 'desktop' and other profiles s.t. maintainers need to add their package with whichever flag should be enabled (qt4 or qt5) to package.use, rather than having the qt* flag(s) globally enabled in the profile -- otherwise we end up with end-users having to deal with it. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXCfk4ACgkQAJxUfCtlWe1CswEA0e4c/gRSbjg0b858+uVFc+z2 +05WUPjFsPpfXrdPs3wA/2r0PyitPRoZAWPWBKm8LhMAC5YIHtjhWA7kh2LTImAQ =gyeU -END PGP SIGNATURE-
[gentoo-portage-dev] [PATCH] similar_name_search: used indexed repos where appropriate (bug 556764)
This reduces the time of 'emerge --info foo' by roughly 24% on my laptop. X-Gentoo-Bug: 556764 X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=556764 --- pym/_emerge/actions.py | 7 +-- pym/_emerge/depgraph.py | 6 +- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py index 92d1f2e..01aef51 100644 --- a/pym/_emerge/actions.py +++ b/pym/_emerge/actions.py @@ -42,6 +42,8 @@ from portage.const import GLOBAL_CONFIG_PATH, VCS_DIRS, _DEPCLEAN_LIB_CHECK_DEFA from portage.const import SUPPORTED_BINPKG_FORMATS, TIMESTAMP_FORMAT from portage.dbapi.dep_expand import dep_expand from portage.dbapi._expand_new_virt import expand_new_virt +from portage.dbapi.IndexedPortdb import IndexedPortdb +from portage.dbapi.IndexedVardb import IndexedVardb from portage.dep import Atom, _repo_separator, _slot_separator from portage.eclass_cache import hashed_path from portage.exception import InvalidAtom, InvalidData, ParseError @@ -1513,9 +1515,10 @@ def action_info(settings, trees, myopts, myfiles): writemsg(\nemerge: searching for similar names... , noiselevel=-1) - dbs = [vardb] + search_index = myopts.get(--search-index, y) != n + dbs = [IndexedVardb(vardb) if search_index else vardb] #if --usepkgonly not in myopts: - dbs.append(portdb) + dbs.append(IndexedPortdb(portdb) if search_index else portdb) if --usepkg in myopts: dbs.append(bindb) diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py index a957108..57040ab 100644 --- a/pym/_emerge/depgraph.py +++ b/pym/_emerge/depgraph.py @@ -21,6 +21,7 @@ from portage.const import PORTAGE_PACKAGE_ATOM, USER_CONFIG_PATH, VCS_DIRS from portage.dbapi import dbapi from portage.dbapi.dep_expand import dep_expand from portage.dbapi.DummyTree import DummyTree +from portage.dbapi.IndexedPortdb import IndexedPortdb from portage.dbapi._similar_name_search import similar_name_search from portage.dep import Atom, best_match_to_list, extract_affecting_use, \ check_required_use, human_readable_required_use, match_from_list, \ @@ -5100,10 +5101,13 @@ class depgraph(object): writemsg(\nemerge: searching for similar names... , noiselevel=-1) + search_index = self._frozen_config.myopts.get(--search-index, y) != n + # fakedbapi is indexed dbs = [vardb] if --usepkgonly not in self._frozen_config.myopts: - dbs.append(portdb) + dbs.append(IndexedPortdb(portdb) if search_index else portdb) if --usepkg in self._frozen_config.myopts: + # bindbapi is indexed dbs.append(bindb) matches = similar_name_search(dbs, atom) -- 2.4.6
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On Wed, Aug 5, 2015 at 8:09 PM, James Cloos cl...@jhcloos.com wrote: WH == William Hubbs willi...@gentoo.org writes: WH What do folks think of these changes? For local filesystems, mount -a is exactly right and should remain. At least for those of us who prefer only ever halving to edit fstab(5). -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 +1 Having yet another place to have to edit to mount local disks is just not a viable option. -- G.Wolfe Woodbury redwo...@gmail.com
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
WH == William Hubbs willi...@gentoo.org writes:
WH The other change I want to make, considering that the mount.* scripts
WH will actually do the work of mounting the file systems, is to turn
WH localmount and netmount into wrappers which will do nothing other than
WH pull in the appropriate mounts. The sys admin would have to configure
WH which mounts are local vs network using settings in
WH /etc/conf.d/{local,net}mount.
WH What do folks think of these changes?
For local filesystems, mount -a is exactly right and should remain. At
least for those of us who prefer only ever halving to edit fstab(5).
Remote filesystems might be differnt, but for local filesystems the
status quo is better.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
