Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 22:52:58 -0400 Walter Dnes waltd...@waltdnes.org wrote: In order for a different init system to come up, some file(s) somewhere *MUST* be different, no ifs/ands/ors/buts. How true is this in general? It is usually only a change of the init parameter. Where is the init parameter changed? Wherever it needs to be changed. [... SNIP] byte-identical hard drives [SNIP ...] You either change it at boot time or on the hard drive. The problem with an eselect approach is that it's like asking a brain surgeon to operate on himself. eselect and wrappers don't operate on themselves, please elaborate. The operating system is changing itself. The world is changing itself. [SNIP to shorten mail] Users can already do this, this isn't a solution. If users can already do it themselves, then why this entire thread? Why do we need eselect/whatever? For the same reason we have all the other eselect modules. http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On 05/29/2013 10:55 PM, William Hubbs wrote: On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote: There are a couple of other possible approaches... 1) If the 2 systems can achieve peacefull co-existance (i.e. no identically-named files with different contents) then simply have 2 boot entries in /etc/lilo.conf (or grub equivalant)... [SNIP to shorten mail] Users can already do this, this isn't a solution. We want to make this easier towards the user, therefore doing heavy discussion to exhaust all the alternatives and maybe someone's interested in implementing one of them that appears most feasible. Since users can already do this, why are we bothering with re-inventing the wheel? How does running an eselect init command make it easier for the user than telling them to edit their boot loader config file? Because to me and many other EFI users is quite annoying having to rebuild the kernel or do something ugly such as editing a binary file. Because it isn't just editing a file or rebuilding the kernel but also have a short trip in single mode to switch back and forth inittab. Because addons such as bootchart2 or e4rat would be much simpler to use through eselect init than doing the whole bootloader or kernel-rebuild dance. Gentoo users are expected to build their kernel and write their boot loader config file initially, so why are we trying to dumb this down? Because usually we aren't linux from scratch and we try to automate as much as we could, leaving the options there to be selected =) lu
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 22:52:58 -0400 Walter Dnes waltd...@waltdnes.org wrote: If users can already do it themselves, then why this entire thread? Why do we need eselect/whatever? The big argument in favour of eselect is that when the procedure for switching things changes, there's no need to worry about users doing the old thing. (That, and if eselect doesn't have it, there will be something far worse showing up on the forums anyway...) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
Tom Wijsman wrote: For the same reason we have all the other eselect modules. http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) As someone else pointed out, not the same thing. Quoting: William Hubbs wrote: Yes, but the init system module that project refers to is already there. Check out eselect rc. It has nothing to do with switching init systems. It appears to be a wrapper around rc-update and a couple of other things to manage init scripts and runlevels. Thanks, William In case you missed the post, thought I would provide it to clear up the matter. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 19:22:32 -0500 William Hubbs willi...@gentoo.org wrote: For the same reason we have all the other eselect modules. We could probably also turn gcc-config into an eselect module if we want to use that argument. Looking at Duncan's reply, that has already happened in the past. Really, think about it, why do we have all those eselect modules at all? Why be inconsistent and not introduce one here? Why keep them around? Well, the answer is simple: Remember that eselect init is optional and an opt-in by emerging it, this is in no way suggested anywhere to become a default on all systems. If you don't want it, fine, but that doesn't stop us from pursuing it... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 19:22:32 -0500 William Hubbs willi...@gentoo.org wrote: We could probably also turn gcc-config into an eselect module if we want to use that argument. Someone did, but unfortunately gcc-config is a big pile of poorly understood voodoo, so eclectic gcc ended up being abandoned. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] 'Local' USE_EXPAND flags -- aka plugins are not that special
Hello,
I've did a quick statistic of how often USE_EXPAND flags are used.
In order to obtain the results, I have put all known USE_EXPANDs into
${flags[@]} and then did:
for a in ${flags[@]}; do
echo -n $a:
grep -l IUSE=.*${a}_ */* | xargs qatom | cut -d' ' -f1-2 | sort -u
| wc -l done | tee /tmp/use-expand.txt
The result was a table of USE_EXPAND flags with counts of how many
*different* packages declare them in IUSE.
The results are:
package count | n flags
---+-
0 | 3
1 | 24
2 | 4
3-8 | 3
10 | 11
As you can see, we have *a lot* of USE_EXPAND variables which are only
used by a *single* package. This feels a lot like people are overusing
USE_EXPANDs in place of local USE flags, just to have them prefixed.
And if you take a look at the detailed list (attached for
completeness), you can see that they really do.
And if anyone wondered why it's wrong -- it's wrong because it's much
like declaring global USE flags for a very specific features which are
not only specific to a single package, but are even defined in a way
that they will *never* be suitable to anything else.
Although most of the cases need to be handled separately
and specifically to a particular flag, a common mistake is to introduce
USE_EXPAND every time plugins or modules are involved.
People, plugins are *not* special. There are regular features, just
packaged in a bit different way.
Let's take an example of a mail client. We have two mail clients, one
tightly integrated and the other plugin-based. Both have optional HTML
message support, the latter in the form of a plugin.
Now, let's assume we have global USE=html (why the heck we don't have
this and instead a dozen of local USE=html, then USE=webkit?!). It is
described as something vague like:
enable HTML support
If I take this USE=html and see it in a mail client, I add 2+2 and get
that USE=html enables HTML message support. Now, why the heck I am
supposed to find out that the latter mail client instead of this
USE=html uses FOO_PLUGINS=htmlviewer?
This looks like a double crime to me. First of all, it's introducing
a specific, local flag for something that we have a global flag for.
Secondly, it's introducing that local flag in a global manner via
USE_EXPAND.
While we actually avoided having that USE_EXPAND for that specific mail
client, there are other cases which are very similar to this.
We have three HTTP servers which define USE_EXPANDs for their modules.
Each of them uses a completely separate namespace and different names
for the *same* features. We have global USE=cgi yet for apache we have
to use apache2_modules_cgi. People are reinventing USE=ssl like this
as well.
And CURL_SSL is a complete disaster. Does supporting 6 different SSL
backends (what for?!) justify inventing a global USE_EXPAND? Most of
those backends have their local (or even global) flags already. Why do
I have to repeat my preference twice?
People, get some reason! The major point of having global USE flags is
to let user express his preferences *once*. Extensively using
USE_EXPAND as a cheap namespace for local flags forces him to re-state
those preferences for every single affected package (USE_EXPAND set).
--
Best regards,
Michał Górny
abi_x86: 86
alsa_cards: 2
alsa_pcm_plugins: 0
apache2_modules: 1
apache2_mpms: 1
calligra_features: 1
cameras: 1
crosscompile_opts: 11
curl_ssl: 2
dracut_modules: 1
dvb_cards: 1
elibc: 1300
fftools: 1
foo2zjs_devices: 0
gpsd_protocols: 1
grub_platforms: 1
input_devices: 5
kernel: 136
lcd_devices: 2
libreoffice_extensions: 1
linguas: 363
lirc_devices: 1
misdn_cards: 0
monkeyd_plugins: 1
netbeans_modules: 1
nginx_modules_http: 1
nginx_modules_mail: 1
ofed_drivers: 1
office_implementation: 8
openmpi_fabrics: 1
openmpi_ofed_features: 1
openmpi_rm: 1
php_targets: 64
python_single_target: 127
python_targets: 808
qemu_softmmu_targets: 1
qemu_user_targets: 2
ruby_targets: 559
sane_backends: 1
userland: 19
video_cards: 24
vmware_guest: 1
voicemail_storage: 1
xfce_plugins: 3
xtables_addons: 1
signature.asc
Description: PGP signature
Re: [gentoo-dev] 'Local' USE_EXPAND flags -- aka plugins are not that special
On 30/05/13 11:58, Michał Górny wrote: Hello, Only replying in behalf of xfce_plugins. Our policy has been always to + enable them by default as they are only used in Xfce specific packages So setting XFCE_PLUGINS= is a way to counter effect that policy This has worked well for us and I don't see a reason to change it, but in general I have to agree, I've seen it overused myself too
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Tue, 28 May 2013 17:15:40 -0500 William Hubbs willi...@gentoo.org wrote: On Tue, May 28, 2013 at 09:07:37PM +0200, Michał Górny wrote: For the others, how large is the benefit of having them switchable? At least some of them look like something that wouldn't hurt people if it was always-built. The dev manual states that use flags are to control optional dependencies and _settings_ which a user may reasonably want to select [1]. William, each time this comes up you overred the _reasonably_. Controlling dependencies is always reasonable but beyond that it's case by case. Just because you can is never a valid reason. Often there are options you clearly only want to toggle if you are a developer or options meant for porting to alternative operating systems which lack some bells and whistles and the like. Another example is configuring a library for bundling with an app. The world is bigger than linux distros. Since the developer gives us the ability to control this with configure switches, I feel pretty strongly that we should give the user that control. Useless options within the given context are an usability issue and those who want to toggle stuff for it's own sake still have EXTRA_ECONF. Ralph William [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/05/13 02:46 AM, Ciaran McCreesh wrote: On Wed, 29 May 2013 19:22:32 -0500 William Hubbs willi...@gentoo.org wrote: We could probably also turn gcc-config into an eselect module if we want to use that argument. Someone did, but unfortunately gcc-config is a big pile of poorly understood voodoo, so eclectic gcc ended up being abandoned. The eselect-gcc wrapper was almost an alias though, wasn't it? ie, it just called gcc-config underneath? Is there interest in reviving this? All of our documentation has discussed using gcc-config directly for so long, i'm not sure if there'd be that much adoption... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGnWh4ACgkQ2ugaI38ACPDikgEAmMoqnaQK7INQvVWWN65DdP2q xQDyGr6X6CR59aZzV8sA/3EBjOBPTH4+SKOUjA4ar0ghlItSCrmWCBjNJdPhIwiQ =d1d+ -END PGP SIGNATURE-
Re: [gentoo-dev] 'Local' USE_EXPAND flags -- aka plugins are not that special
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/30/2013 06:26 AM, Samuli Suominen wrote: On 30/05/13 11:58, Michał Górny wrote: Hello, Only replying in behalf of xfce_plugins. Our policy has been always to + enable them by default as they are only used in Xfce specific packages So setting XFCE_PLUGINS= is a way to counter effect that policy This has worked well for us and I don't see a reason to change it, but in general I have to agree, I've seen it overused myself too I remember when the use expand was first added for XFCE stuff, nothing worked on my system for days while I tried to figure out what was wrong because I was only looking at the regular use flags. - -- (that's minus minus) on use_expand in general. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRp2FaAAoJEKXdFCfdEflKm9UP/2aNOl5dwuz3NPTOy2p8j/Ai ufytkKGn2dG1vt49KUcqPsXlZTMFuJzZ/uEgmuchc+InDX8VrmUTzrkl1Z/HbtfJ 21wts/YBjoh/6Iar6QehG/wRXY2E5kJCMNb8/c76Kf1ho1sUne9sHB6URkjggcVy VOlf6bJFYXMW74hWzLBnXmDYHNjQL0qKJ9EpoV2zKGnkYgxeGsk4/AX2vosxZNcd s36sSY+EeSW0Sot1zRD1rvFaRDXYQBKjpcyTMcy4ptExarl3rdoyI0dCjwtYJ4Ah c0y/Lfr5KRIJMSDrmNFcx6WUdV34lAk3NxwWvYqdMxBSAHt9CP3Bb3l2llhdoxjJ BbIkZU2rXCaFcC1Ikk7KBSGd+0pLnadiGUsaD/VKYalZ9L4ZiICqX4G3lQx6ziFf S9ZjwQBIKniTGpRkYAUrlrVRlzXY9y9J3W3JOzQ/A/XyJZC1Xc5D7RAVHMugeCng sMKiGCps2PRTtcpdQ1BxhFiX8feAOuY3gIDImlNPESrbseTqDU6+JvEF1GRy4FYw NgufcZDD3jMrhKG7RubKymTBbASk9VyGCWQ8v/kSV1B8CJZxGp4NgxTWz/PJBkNV 2TOhkkjJvXafRVUVcld8Wjj5RpdCKAp9ZC3RAmrqTCAq2p2LHsDiS1ggtpmlvEuY 0ylVxotYBUHwGDP9Xsg3 =q+kU -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Thu, May 30, 2013 at 08:35:22AM +0200, Tom Wijsman wrote: Remember that eselect init is optional and an opt-in by emerging it, this is in no way suggested anywhere to become a default on all systems. Ok, that's cool then, I just would hate to see it become a default. William signature.asc Description: Digital signature
[gentoo-dev] inittab was: Re: Switchup-mode and boottime selector? Was: eselect init
On Thu, May 30, 2013 at 08:30:00AM +0200, Luca Barbato wrote: Because it isn't just editing a file or rebuilding the kernel but also have a short trip in single mode to switch back and forth inittab. inittab is only used by sysvinit and busybox init right? If so, it is unfortunate that busybox init uses inittab and its inittab is not compatible with sysvinit. I'm tending to agree with mgorny that a better fix for this might be to have busybox use an alternate filename for its inittab, i.e. first look for /etc/bb-inittab and use it, then if it can't find that, use /etc/inittab as a fallback. What do you think? William signature.asc Description: Digital signature
Re: [gentoo-dev] New USE_EXPAND: CLAWS_MAIL_PLUGINS
On 04/24/2013 12:48 PM, René Neumann wrote: Am 24.04.2013 19:15, schrieb Zac Medico: On 04/24/2013 02:51 AM, René Neumann wrote: As more and more packages seem to (mis)use USE_EXPAND: Can we get the possibility to set this directly in package.use? Having to write 'claws_mail_plugins_foo' does not help readability, and setting it in make.conf is also not the right way (as is package.env). How about if we use a share a single PLUGINS USE_EXPAND among multiple unrelated packages? That way, you're package.use settings will be less verbose (plugins_foo versus claws_mail_plugins_foo). And could anyone explain to me, why having 21 additional use-flags is bad? I mean, you have them now too, the only 'advantage' being a nicer display on 'emerge -v'. Using a generic PLUGINS USE_EXPAND will also have the advantage of making the emerge -v display less verbose. Yes, this sounds like a good compromise. I'd still go with Michał if I had to choose ... but I'm not the maintainer :). We've got a feature request bug here for a package.use USE_EXPAND syntax extension: https://bugs.gentoo.org/show_bug.cgi?id=471776 -- Thanks, Zac
[gentoo-dev] Re: inittab was: Re: Switchup-mode and boottime selector? Was: eselect init
On 05/30/2013 10:52 PM, William Hubbs wrote: On Thu, May 30, 2013 at 08:30:00AM +0200, Luca Barbato wrote: Because it isn't just editing a file or rebuilding the kernel but also have a short trip in single mode to switch back and forth inittab. inittab is only used by sysvinit and busybox init right? By anything that claims to be init-compatible. If so, it is unfortunate that busybox init uses inittab and its inittab is not compatible with sysvinit. Surely is. I'm tending to agree with mgorny that a better fix for this might be to have busybox use an alternate filename for its inittab, i.e. first look for /etc/bb-inittab and use it, then if it can't find that, use /etc/inittab as a fallback. sending patches should be easy. What do you think? I stated the worst cases, I guess is time to draft stuff and see how it does behave. lu
