On 03/01/2014 12:28 AM, Samuli Suominen wrote:
>
> On 01/03/14 04:55, Joshua Kinard wrote:
>> 3. Some profiles also override INSTALL_MASK, such as Gentoo/FreeBSD, because
>> systemd does not apply there.
>
> Wow. I don't think we should allow this without first having exactly
> what was suggested in this thread, a way of redefining the order
> away from INSTALL_MASK_ORDER="profile:ebuild:user", because
> if we allow INSTALL_MASK usage in profiles without having a setting
> for the order, it'll always be INSTALL_MASK_ORDER="profile:user",
> and it's very hard for user to get his setting respected even if he
> wanted to.
It's in /usr/portage/profiles/default/bsd/make.defaults it looks. I only
noticed it in a test VM running Gentoo/FreeBSD that every package merge
printed out "* Removing /usr/lib/systemd ...". Being in make.defaults, it
should be overridable by the user in their systems make.conf, right?
Not sure how it affects overriding by an individual ebuild, if that
functionality is ever supported.
>>
>> Would it make sense to have the systemd/udev ebuilds check for the existence
>> of an overridden INSTALL_MASK variable and then print a very *loud* warning
>> to the user IF systemd is already installed OR if the user is installing it
>> for the first time (possibly to test it out or actually switching to it)?
>> The warning will also fire if packages containing unit files are
>> installed/upgraded. Such a warning could include a link to a Wiki article
>> explaining things in further detail, as well as stating bugs created as a
>> result of ignoring this message will be automatically closed as
>> RESOLVED::WONTFIX.
>
> The most common opinion in this thread seems to be 'this is all just
> overkill,
> and you are on your own...'
> But adding such hackery to ebuilds when this is no way udev or systemd
> specific problem to begin, would be much, much bigger overkill (or rather,
> should I say, underkill? :-)
When in doubt, nuke it from orbit first, collapse the star into a
singularity second, then ask questions third. In layman's terms, you can
never have too big of a hammer.
Basically what I am suggesting is finding a sane way to politely tell users
who set INSTALL_MASK locally that specific to systemd/udev packages, they
risk breaking their system if using it or migrating to it. Optionally,
telling them the same thing if they install a package that also installs
unit files.
TBH, expanding on the idea, it doesn't even have to be specific to
systemd/udev, but a generic framework that can be used by ebuilds to warn
the user of invalid configurations that could render a system package (or
their system) unusable unless they change their configuration.
This still leaves the power in the hands of the user to configure things how
they want (E.g., setting INSTALL_MASK). It also allows us devs to avoid
adding another variable into an already complex equation (having to decide
on INSTALL_MASK_ORDER settings for all archs/profiles). Package maintainers
are free to check for known problematic settings in make.conf or the envvars
and warn the user appropriately in their packages. If the user chooses to
proceed anyways, well, they were warned...
W/o grepping the tree, I wouldn't be surprised if some ebuilds already do
this in some form. Basic grep on make.conf, ewarn or eerror if a problem
setting is discovered. Setup some function in eutils instead to do this:
echeck_var_warn("INSTALL_MASK", "/usr/lib/systemd")
echeck_var_error("INSTALL_MASK", "/usr/lib/systemd")
Etc...
Brainstorming. If the idea is silly or nonsensical, well, then someone
propose something better.
Squirrel.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
