[gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Samuli Suominen]

It would be very helpful if INSTALL_MASK could be overriden from an
ebuild, if user hasn't
set otherwise.
So it could be configured like USE_ORDER which is
"env:pkg:conf:defaults:pkginternal:repo:env.d"
So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
This would be very helpful in preventing people from shooting themself
in the foot

The only problem is that I propably don't have enough python skills to
make that happen w/
sys-apps/portage. But does the suggestion make sense? Should I open a
feature request bug?

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Tom Wijsman]

On Fri, 28 Feb 2014 15:28:30 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, ...

What is the intended goal? Can you give an example?

Ebuilds can already clean out their own image during install; as for
installing an INSTALL_MASK file, that doesn't make it actually
removes those files from the system which would mean that re-emerging
is necessary to make it happen. Unless we build introduce some post
install task that evaluates INSTALL_MASK and removes _everything_.

> ... if user hasn't set otherwise.
>
> So it could be configured like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"

That sounds like unstable behavior, example scenario:

1. User has INSTALL_MASK unset.
2. User installs packages with it unset.
3. User installs your package, the ebuild INSTALL_MASK set.
4. User installs packages with the ebuild INSTALL_MASK set.
5. User sets INSTALL_MASK.
6. User installs packages with his/her INSTALL_MASK set.

The paths listed in the ebuild INSTALL_MASK are only masked in (4).

> This would be very helpful in preventing people from shooting themself
> in the foot

What do we try to prevent here? How would it prevent them from doing so?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Michael Palimaka]

On 03/01/2014 12:28 AM, Samuli Suominen wrote:
> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, if user hasn't
> set otherwise.
> So it could be configured like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
> This would be very helpful in preventing people from shooting themself
> in the foot
> 
> The only problem is that I propably don't have enough python skills to
> make that happen w/
> sys-apps/portage. But does the suggestion make sense? Should I open a
> feature request bug?
> 
> 

If you're using INSTALL_MASK, isn't it assumed that you're on your own
and bugs filed while using it are invalid? Do we have to create
REAL_INSTALL_MASK for people that really wanted those files removed anyway?

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Lars Wendler]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:

>It would be very helpful if INSTALL_MASK could be overriden from an
>ebuild, if user hasn't
>set otherwise.
>So it could be configured like USE_ORDER which is
>"env:pkg:conf:defaults:pkginternal:repo:env.d"
>So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
>This would be very helpful in preventing people from shooting themself
>in the foot
>
>The only problem is that I propably don't have enough python skills to
>make that happen w/
>sys-apps/portage. But does the suggestion make sense? Should I open a
>feature request bug?
>

No need for if the ebuild(s) would use sane installation paths.

Please finally stop imposing your insane ideas upon us, thanks.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Samuli Suominen]

On 28/02/14 16:41, Lars Wendler wrote:
> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
>
>> It would be very helpful if INSTALL_MASK could be overriden from an
>> ebuild, if user hasn't
>> set otherwise.
>> So it could be configured like USE_ORDER which is
>> "env:pkg:conf:defaults:pkginternal:repo:env.d"
>> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
>> This would be very helpful in preventing people from shooting themself
>> in the foot
>>
>> The only problem is that I propably don't have enough python skills to
>> make that happen w/
>> sys-apps/portage. But does the suggestion make sense? Should I open a
>> feature request bug?
>>
> No need for if the ebuild(s) would use sane installation paths.
>
> Please finally stop imposing your insane ideas upon us, thanks.
>

You should stop attacking people. Period.

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Samuli Suominen]

On 28/02/14 16:18, Tom Wijsman wrote:
> On Fri, 28 Feb 2014 15:28:30 +0200
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> It would be very helpful if INSTALL_MASK could be overriden from an
>> ebuild, ...
> What is the intended goal? Can you give an example?

- User has INSTALL_MASK="/lib/systemd"
- Ebuild has INSTALL_MASK_OVERRIDE="/lib/systemd/systemd-udevd
/lib/systemd/network"
- Portage's default is to respect ebuild first, then users setting,
unless he changes INSTALL_MASK_ORDER to respect his

I completely agree using INSTALL_MASK is 100% responsibility of the user
setting it, it's like blind 'rm -f', but some people
don't agree and keep attacking me.
I'm using the word attacking because it's constant, relentless,
repeating and I don't see an end to it. I believe Poly-C just
proofed that point in this thread.

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Samuli Suominen:
> It would be very helpful if INSTALL_MASK could be overriden from
> an ebuild, if user hasn't set otherwise. So it could be configured
> like USE_ORDER which is 
> "env:pkg:conf:defaults:pkginternal:repo:env.d" So
> INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}" This
> would be very helpful in preventing people from shooting themself 
> in the foot
> 
> The only problem is that I propably don't have enough python skills
> to make that happen w/ sys-apps/portage. But does the suggestion
> make sense? Should I open a feature request bug?
> 

Introducing something like INSTALL_MASK_ORDER gives the user
effectively more ways to shoot himself in the foot, especially when
ebuilds start to rely on INSTALL_MASK in non-trivial ways (and I am
sure people will come up with stuff).

Besides that, it is a very intrusive change of behavior.

Anyway... I don't care about people who break their systems in such
stupid ways. It's not more dangerous than one of the other thousand
things you can do to break gentoo, such as "--nodeps".

They gotta handle it.
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJTEKRNAAoJEFpvPKfnPDWz0hwH/3ul98sKbspOZXdjvH2abZKV
HCGPlrSNDkwErI0DiemsVeW68DtaUzMHDhk3dIDX2ZJan0hychXKwNXaTq+23X9K
GLioxGKS+WZpqCrJ8sQjxhRgyhLkDVSwQE5Qq03hQdPxTaekfRRprR7spNRDnRFB
vg1VBbsNhAIfGWSSRvmTo/C+b0qb56dr2eUEHwTM78fjylzo6Ndt/Ks8tFf/sMta
8EdiivY84KUKmX916Wqmf44Xo58AWrjoqQ8LPeWyKkcLbnfKv1wSIcbPYaBLWOG9
HPhZPzM+6VR3LmNpR6Xsq+IQ642ky5dact8aBstQrLBepaHeXsROJcipoolmgMw=
=WOX9
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Samuli Suominen]

On 28/02/14 16:59, hasufell wrote:
> Samuli Suominen:
> > It would be very helpful if INSTALL_MASK could be overriden from
> > an ebuild, if user hasn't set otherwise. So it could be configured
> > like USE_ORDER which is
> > "env:pkg:conf:defaults:pkginternal:repo:env.d" So
> > INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}" This
> > would be very helpful in preventing people from shooting themself
> > in the foot
>
> > The only problem is that I propably don't have enough python skills
> > to make that happen w/ sys-apps/portage. But does the suggestion
> > make sense? Should I open a feature request bug?
>
>
> Introducing something like INSTALL_MASK_ORDER gives the user
> effectively more ways to shoot himself in the foot, especially when
> ebuilds start to rely on INSTALL_MASK in non-trivial ways (and I am
> sure people will come up with stuff).
>
> Besides that, it is a very intrusive change of behavior.
>
> Anyway... I don't care about people who break their systems in such
> stupid ways. It's not more dangerous than one of the other thousand
> things you can do to break gentoo, such as "--nodeps".
>
> They gotta handle it.

I'm okay with that. That's how I see it too. I was merely trying to
propose a solution
for some users (and even few developers).

At least I have this thread now I can refer them to in gmane, to show it
was discussed
and the general consensus is what it is and that they have to take
responsibility for
their INSTALL_MASK, not me, or any other ebuild maintainer.

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/02/14 09:59 AM, hasufell wrote:
> Samuli Suominen:
>> It would be very helpful if INSTALL_MASK could be overriden from
>>  an ebuild, if user hasn't set otherwise. So it could be 
>> configured like USE_ORDER which is 
>> "env:pkg:conf:defaults:pkginternal:repo:env.d" So 
>> INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}" This
>>  would be very helpful in preventing people from shooting
>> themself in the foot
> 
>> The only problem is that I propably don't have enough python 
>> skills to make that happen w/ sys-apps/portage. But does the 
>> suggestion make sense? Should I open a feature request bug?
> 
> 
> Introducing something like INSTALL_MASK_ORDER gives the user 
> effectively more ways to shoot himself in the foot, especially when
> ebuilds start to rely on INSTALL_MASK in non-trivial ways (and I am
> sure people will come up with stuff).
> 
> Besides that, it is a very intrusive change of behavior.
> 
> Anyway... I don't care about people who break their systems in such
> stupid ways. It's not more dangerous than one of the other thousand
> things you can do to break gentoo, such as "--nodeps".
> 
> They gotta handle it.
> 

I'm with hasufell here.  INSTALL_MASK is a Big Freakin' Hammer; it
should stay that way and we should just focus on ensuring users that
use it know exactly what they are getting into.

That said, what we could do (if this isn't done already) is have
portage automatically elog or ewarn what files are excluded from the
system on merge time due to the INSTALL_MASK.  At least that way,
users would be able to see in the log what files were removed, so when
something they need -is- removed they'll be able to see that right away.
(note, i've never used INSTALL_MASK, so I've no idea what portage reports)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMQqWkACgkQ2ugaI38ACPA+mQEAkb7Gka8o+/sTIKqxWOvyoy8L
4QM0E725U0fFB6dWqMEA/1sy2vluJUINbyl3Os/F55NlQ9f2rt0f92cCA9scdJ5v
=NRRC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Samuli Suominen]

On 28/02/14 17:24, Anthony G. Basile wrote:
> On 02/28/2014 08:28 AM, Samuli Suominen wrote:
>> It would be very helpful if INSTALL_MASK could be overriden from an
>> ebuild, if user hasn't
>> set otherwise.
>> So it could be configured like USE_ORDER which is
>> "env:pkg:conf:defaults:pkginternal:repo:env.d"
>> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
>> This would be very helpful in preventing people from shooting themself
>> in the foot
>>
>> The only problem is that I propably don't have enough python skills to
>> make that happen w/
>> sys-apps/portage. But does the suggestion make sense? Should I open a
>> feature request bug?
>>
> What would be the purpose?  Can you give me a use case.
>

 I already did, earlier in this thread. Please refer to it.

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Anthony G. Basile]

On 02/28/2014 08:28 AM, Samuli Suominen wrote:
> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, if user hasn't
> set otherwise.
> So it could be configured like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
> This would be very helpful in preventing people from shooting themself
> in the foot
>
> The only problem is that I propably don't have enough python skills to
> make that happen w/
> sys-apps/portage. But does the suggestion make sense? Should I open a
> feature request bug?
>
What would be the purpose?  Can you give me a use case.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Rich Freeman]

On Fri, Feb 28, 2014 at 9:44 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> I completely agree using INSTALL_MASK is 100% responsibility of the user
> setting it, it's like blind 'rm -f', but some people
> don't agree and keep attacking me.
> I'm using the word attacking because it's constant, relentless,
> repeating and I don't see an end to it. I believe Poly-C just
> proofed that point in this thread.
>

Honestly, that is a problem in need of a non-technical solution.

The purpose of INSTALL_MASK is for users to tell portage, "I know what
I'm doing, don't mess with this path."  Portage should do as it is
told.  If the user doesn't know what they're doing, they get to keep
the pieces.  If somebody gives you a hard time about it, there are
solutions for that.

I think using INSTALL_MASK to kill a few inodes that probably don't
even have extents using a sledgehammer to kill a fly, and if you put
some holes in your walls in the process I_TOLD_YOU_SO.  However, I
won't tell people they can't do it if they want to.  It has a lot of
uses I'd consider more productive in setting up embedded systems and
such, and in those cases having a war of escalation with overrides on
top of overrides is just a PITA.

Honestly, if we were going to do all this, the people annoyed by
systemd units will just apply the override, and you'll be right back
where you are now.

So, regardless of where you fall on the debates around FHS, install of
units without use flag, and so on, I don't think changing how
INSTALL_MASK works really makes sense.

By all means we can continue those debates and get Council votes where
appropriate.

Rich

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Thomas D.]

Hi,

Ian Stakenvicius wrote:
> That said, what we could do (if this isn't done already) is have 
> portage automatically elog or ewarn what files are excluded from
> the system on merge time due to the INSTALL_MASK.  At least that
> way, users would be able to see in the log what files were removed,
> so when something they need -is- removed they'll be able to see
> that right away. (note, i've never used INSTALL_MASK, so I've no
> idea what portage reports)

That's already happening.

For example an INSTALL_MASK

  INSTALL_MASK="/etc/systemd/"
  INSTALL_MASK="${INSTALL_MASK} /lib/systemd/"
  INSTALL_MASK="${INSTALL_MASK} /lib64/systemd/"
  INSTALL_MASK="${INSTALL_MASK} /usr/lib/systemd/"
  INSTALL_MASK="${INSTALL_MASK} /usr/lib64/systemd/"

is given. When you emerge a package you will see messages like

  [...]

  >>> Installing (1 of 1) sys-fs/udev-210
   * Removing /etc/systemd/
   * Removing /lib/systemd/
   * Removing /lib64/systemd/
   * Removing /usr/lib/systemd/
   * Removing /usr/lib64/systemd/
   * checking 51 files for package collisions
  >>> Merging sys-fs/udev-210 to /

  [...]

If you keep logs, elogv for example will also show this information:

  │ [...]                        │
  │                              │
  │INFO: other                   │
  │Removing /etc/systemd/        │
  │Removing /lib/systemd/        │
  │Removing /lib64/systemd/      │
  │Removing /usr/lib/systemd/    │
  │Removing /usr/lib64/systemd/  │

The downside is that this message will always appear when you have set
an INSTALL_MASK. Even for packages which don't install anything into
the masked paths. So people maybe tend to ignore this information
because it is always shown :)

If this message would only be shown if the merged package is *really*
affected by the INSTALL_MASK, this would be an improvement.


-Thomas

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/02/14 11:17 AM, Thomas D. wrote:
> Hi,
> 
> Ian Stakenvicius wrote:
>> That said, what we could do (if this isn't done already) is have
>>  portage automatically elog or ewarn what files are excluded
>> from the system on merge time due to the INSTALL_MASK.  At least
>> that way, users would be able to see in the log what files were
>> removed, so when something they need -is- removed they'll be able
>> to see that right away. (note, i've never used INSTALL_MASK, so
>> I've no idea what portage reports)
> 
> That's already happening.
> 
> For example an INSTALL_MASK
> 
> INSTALL_MASK="/etc/systemd/" INSTALL_MASK="${INSTALL_MASK}
> /lib/systemd/" INSTALL_MASK="${INSTALL_MASK} /lib64/systemd/" 
> INSTALL_MASK="${INSTALL_MASK} /usr/lib/systemd/" 
> INSTALL_MASK="${INSTALL_MASK} /usr/lib64/systemd/"
> 
> is given. When you emerge a package you will see messages like
> 
> [...]
> 
>>>> Installing (1 of 1) sys-fs/udev-210
> * Removing /etc/systemd/ * Removing /lib/systemd/ * Removing
> /lib64/systemd/ * Removing /usr/lib/systemd/ * Removing
> /usr/lib64/systemd/ * checking 51 files for package collisions
>>>> Merging sys-fs/udev-210 to /
> 
> [...]
> 
> If you keep logs, elogv for example will also show this
> information:
> 
> │ [...]                        │ │                              │ 
> │INFO: other                   │ │Removing /etc/systemd/        │ 
> │Removing /lib/systemd/        │ │Removing /lib64/systemd/      │ 
> │Removing /usr/lib/systemd/    │ │Removing /usr/lib64/systemd/  │
> 
> The downside is that this message will always appear when you have
> set an INSTALL_MASK. Even for packages which don't install anything
> into the masked paths. So people maybe tend to ignore this
> information because it is always shown :)
> 
> If this message would only be shown if the merged package is
> *really* affected by the INSTALL_MASK, this would be an
> improvement.

That just seems to be showing what paths are in the INSTALL_MASK and
are removed.  What I mean, rather, is that effectively the output of:

for mypath in ${INSTALL_MASK}; do find ${D}${mypath} -type f ; done

...would be reported an an elog/ewarn, ie, the actual directory tree
that is going to be removed.  This would also have the benefit of not
reporting anything if no files are being installed/merged under any of
the INSTALL_MASK locations..



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMQuRoACgkQ2ugaI38ACPDJnQD/e3+Sueyf+3gJSkL6GKVQJ6fA
cQo1Ogxo7Sk2ivzvA7UA/3zYVLSaaEXOsAAcEx6skXqgqIgESO9wSeXUjJvuYn5G
=m5Y2
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ian Stakenvicius:
> On 28/02/14 11:17 AM, Thomas D. wrote:
>> Hi,
> 
>> Ian Stakenvicius wrote:
>>> That said, what we could do (if this isn't done already) is
>>> have portage automatically elog or ewarn what files are
>>> excluded from the system on merge time due to the INSTALL_MASK.
>>> At least that way, users would be able to see in the log what
>>> files were removed, so when something they need -is- removed
>>> they'll be able to see that right away. (note, i've never used
>>> INSTALL_MASK, so I've no idea what portage reports)
> 
>> That's already happening.
> 
>> For example an INSTALL_MASK
> 
>> INSTALL_MASK="/etc/systemd/" INSTALL_MASK="${INSTALL_MASK} 
>> /lib/systemd/" INSTALL_MASK="${INSTALL_MASK} /lib64/systemd/" 
>> INSTALL_MASK="${INSTALL_MASK} /usr/lib/systemd/" 
>> INSTALL_MASK="${INSTALL_MASK} /usr/lib64/systemd/"
> 
>> is given. When you emerge a package you will see messages like
> 
>> [...]
> 
>>>>> Installing (1 of 1) sys-fs/udev-210
>> * Removing /etc/systemd/ * Removing /lib/systemd/ * Removing 
>> /lib64/systemd/ * Removing /usr/lib/systemd/ * Removing 
>> /usr/lib64/systemd/ * checking 51 files for package collisions
>>>>> Merging sys-fs/udev-210 to /
> 
>> [...]
> 
>> If you keep logs, elogv for example will also show this 
>> information:
> 
>> │ [...]                        │ │
>> │ │INFO: other                   │ │Removing /etc/systemd/
>> │ │Removing /lib/systemd/        │ │Removing /lib64/systemd/
>> │ │Removing /usr/lib/systemd/    │ │Removing /usr/lib64/systemd/
>> │
> 
>> The downside is that this message will always appear when you
>> have set an INSTALL_MASK. Even for packages which don't install
>> anything into the masked paths. So people maybe tend to ignore
>> this information because it is always shown :)
> 
>> If this message would only be shown if the merged package is 
>> *really* affected by the INSTALL_MASK, this would be an 
>> improvement.
> 
> That just seems to be showing what paths are in the INSTALL_MASK
> and are removed.  What I mean, rather, is that effectively the
> output of:
> 
> for mypath in ${INSTALL_MASK}; do find ${D}${mypath} -type f ;
> done
> 
> ...would be reported an an elog/ewarn, ie, the actual directory
> tree that is going to be removed.  This would also have the benefit
> of not reporting anything if no files are being installed/merged
> under any of the INSTALL_MASK locations..
> 
> 
> 
> 

Yes, that would make it easier to catch funny things. I remember a bug
report where some user was messing with INSTALL_MASK and
"/usr/share/locale/" and didn't notice that he effectively removed all
language support... and started filing random bug reports. Took quite
a while before someone spotted that crap in "emerge --info".
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJTELpnAAoJEFpvPKfnPDWzW7kIAIqxnVP7ToRXh7kG8M+dIqyA
qZvVnLUcMHsIkw4cbWNMwAHiRhuSnhzoT6aY/LWT3VD3AxHfIjlI2ylbTihl7Q4c
XLCusLk1HdHQWJN9yZJcUrwZNzTQSCi54xZBq8CelC5cK5k9w4MNSpje/NsbMfWC
jRDIUjbRVbDfkHVDxzRLCewnNnvrGa1yhibMR9fcQ2Nh8ifVQZdBavwBJiZ45bhJ
1vzNbrr2ghfl6Rza+yA+tjQRU4MvTR4CaIrtBkSHwZopwyuSBBhhAjj2pzrQDakP
56XsUDmZ528h1+0Qen81I6Ms9SffoRAqCcs/6YrdEDXQESDuzwCEB7U5cOZXvlA=
=BW6V
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Lars Wendler]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:

>
>On 28/02/14 16:41, Lars Wendler wrote:
>> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
>>
>>> It would be very helpful if INSTALL_MASK could be overriden from an
>>> ebuild, if user hasn't
>>> set otherwise.
>>> So it could be configured like USE_ORDER which is
>>> "env:pkg:conf:defaults:pkginternal:repo:env.d"
>>> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
>>> This would be very helpful in preventing people from shooting
>>> themself in the foot
>>>
>>> The only problem is that I propably don't have enough python skills
>>> to make that happen w/
>>> sys-apps/portage. But does the suggestion make sense? Should I open
>>> a feature request bug?
>>>
>> No need for if the ebuild(s) would use sane installation paths.
>>
>> Please finally stop imposing your insane ideas upon us, thanks.
>>
>
>You should stop attacking people. Period.

Once you stop trying to make things worse in Gentoo I will consider
stopping my attacks... so it's up to you.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/02/14 12:01 PM, Lars Wendler wrote:
> On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:
>> 
>> You should stop attacking people. Period.
> 
> Once you stop trying to make things worse in Gentoo I will
> consider stopping my attacks... so it's up to you.
> 


c'mon, guys -- at least take it off-list please.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMQwtsACgkQ2ugaI38ACPCo5wD/YPGn+EASdDhubWDAqB9JPXGN
d3orh/2FuT7MuHnIl0YA/A7d2VD2DqCbYmtmfRI3ty2eN1EiPCeeTBLfwdC8UKkR
=dbo6
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Samuli Suominen]

On 28/02/14 19:01, Lars Wendler wrote:
> On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:
>
>> On 28/02/14 16:41, Lars Wendler wrote:
>>> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
>>>
>>>> It would be very helpful if INSTALL_MASK could be overriden from an
>>>> ebuild, if user hasn't
>>>> set otherwise.
>>>> So it could be configured like USE_ORDER which is
>>>> "env:pkg:conf:defaults:pkginternal:repo:env.d"
>>>> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
>>>> This would be very helpful in preventing people from shooting
>>>> themself in the foot
>>>>
>>>> The only problem is that I propably don't have enough python skills
>>>> to make that happen w/
>>>> sys-apps/portage. But does the suggestion make sense? Should I open
>>>> a feature request bug?
>>>>
>>> No need for if the ebuild(s) would use sane installation paths.
>>>
>>> Please finally stop imposing your insane ideas upon us, thanks.
>>>
>> You should stop attacking people. Period.
> Once you stop trying to make things worse in Gentoo I will consider
> stopping my attacks... so it's up to you.
>

Is there anything you'd like to add before I open the comrel bug about
baseless accusation of making things intentionally worse?

- Samuli

[gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Duncan]

hasufell posted on Fri, 28 Feb 2014 16:33:43 +0000 as excerpted:

> I remember a bug report where some user was messing with INSTALL_MASK
> and "/usr/share/locale/" and didn't notice that he effectively removed
> all language support... and started filing random bug reports. Took
> quite a while before someone spotted that crap in "emerge --info".

Interesting.  I have /usr/share/locale/ in my INSTALL_MASK precisely in 
ordered to remove the language support I don't need anyway, and have had 
it there for a very long time, with no visible ill effects.  I'd like to 
know why someone would put a locale dir in their INSTALL_MASK in the 
first place if they weren't purposefully trying to kill unnecessary 
locale support...

(FWIW, I don't use a more general */locale/ mask precisely because I'm 
not sure the global effects would be viable, tho it sure would make 
things simpler for all the packages with their own locale dirs.)

-- 
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] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

Dnia 2014-02-28, o godz. 15:28:30
Samuli Suominen <ssuominen@gentoo.org> napisał(a):

> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, if user hasn't
> set otherwise.
> So it could be configured like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
> This would be very helpful in preventing people from shooting themself
> in the foot
> 
> The only problem is that I propably don't have enough python skills to
> make that happen w/
> sys-apps/portage. But does the suggestion make sense? Should I open a
> feature request bug?

I don't think this really makes sense. It sounds like putting a new
carpet on top of spoiled milk.

INSTALL_MASK is pretty much complete by itself. Letting ebuilds
override INSTALL_MASK is pretty much going against the main goal
of INSTALL_MASK. And this is going to cause users to want to override
the override...

Which, pretty much, means that the hacks are going to pile up.

How about just checking INSTALL_MASK in pkg_pretend() and dying when it
removes udev? That should work and be quite easy to implement.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Steev Klimaszewski]

On Fri, 2014-02-28 at 10:31 -0500, Rich Freeman wrote:
> 
> I think using INSTALL_MASK to kill a few inodes that probably don't
> even have extents using a sledgehammer to kill a fly, and if you put
> some holes in your walls in the process I_TOLD_YOU_SO.  However, I
> won't tell people they can't do it if they want to.  It has a lot of
> uses I'd consider more productive in setting up embedded systems and
> such, and in those cases having a war of escalation with overrides on
> top of overrides is just a PITA.
> 

Please keep in mind that not every device that runs Gentoo has the
ability to just pop new storage in with more space.  The Beaglebone
Black has 2GB eMMC.  Some of the EfikaMX smarttops have 4GB PATA ssd.
It's a PITA to deal with upstreams that have some interesting ideas, as
well as maintainers that insist that the upstreams ideas are sound.
Part of our "jobs" as Gentoo maintainers is to actually maintain
software as it pertains to Gentoo, not to blindly copy what upstream
does and call it a day.  If something makes no sense, we should not
point and scream UPSTREAM DOES IT, DISTROX DOES IT - if they do it, and
all we are doing is blindly copying them, why not just run DISTROX!?

I'm not exactly a fan of systemd, though I know it has some uses, and
I'm still curious as to why it installs/stores *configuration* data
in /lib - if only from an upgrade point of view, we back up /etc, we
back up /home - now we need to back up /lib, /usr/lib, /var, or whatever
some random upstream decides is a good place to store configuration
information!?  

I get it, we all are busy, we have better things to do than patch things
from upstream, but sometimes, it's a requirement.  We wouldn't install a
script that does rm -rf / with root permissions (assuming a non-hardened
box where it would cause quite a bit of damage) - but we're okay with
just randomly storing configuration data all over the system?  Please
consider these things before saying we're going to blindly follow
upstream - if something is too hard for you to maintain, ask for some
assistance in doing so.  

And please keep in mind that while we are all doing these things to
scratch our own itches, there are other people's systems involved too
that don't have the same luxuries we have.

-- Steev

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Rich Freeman]

On Fri, Feb 28, 2014 at 8:09 PM, Steev Klimaszewski <steev@gentoo.org> wrote:
> Please keep in mind that not every device that runs Gentoo has the
> ability to just pop new storage in with more space.  The Beaglebone
> Black has 2GB eMMC.

Hence the reason I suggested that embedded systems are a perfect case
where INSTALL_MASK makes sense.  I'm all for having the feature there
for users to use.

> I'm not exactly a fan of systemd, though I know it has some uses, and
> I'm still curious as to why it installs/stores *configuration* data
> in /lib - if only from an upgrade point of view, we back up /etc, we
> back up /home - now we need to back up /lib, /usr/lib, /var, or whatever
> some random upstream decides is a good place to store configuration
> information!?

Why would you back up default config settings, except as part of a
full system backup including all the binaries/libs/etc?  If you lose a
file in /usr you just re-install the package and it will be there.

Users aren't supposed to edit any of the config files in /usr, just as
they're not supposed to edit make.defaults in /usr.  If they don't
like what a unit file or udev rule in /usr does, they just have to
stick a corresponding file in /etc to override it, and that of course
should be backed up.

If they just hard-coded the defaults in the source code, would that
make it better (in which case it would be in /usr, and far more opaque
- and this is traditionally how these things were done)?

>
> I get it, we all are busy, we have better things to do than patch things
> from upstream, but sometimes, it's a requirement.  We wouldn't install a
> script that does rm -rf / with root permissions (assuming a non-hardened
> box where it would cause quite a bit of damage) - but we're okay with
> just randomly storing configuration data all over the system?  Please
> consider these things before saying we're going to blindly follow
> upstream - if something is too hard for you to maintain, ask for some
> assistance in doing so.

Nobody is saying that we should follow upstream simply for its own
sake.  However, we shouldn't change things when there is no real
benefit to doing so.  How is sticking a bunch of template config files
that users aren't supposed to touch in /etc helpful?  How is removing
"systemd" from filenames helpful?  How is sticking a few files in /lib
instead of /usr/lib more helpful than sticking copies of them in an
initramfs?

And I don't see the value in the more traditional config file style
where you just give the user one huge file and allow them to use
etc-update/etc to constantly re-merge changes into it.  I greatly
appreciate having a 8 line file in /etc/X11/xorg.conf.d vs what my
config files used to look like.  I still have a backup of XF86Config
in /etc from 2004 and it is 464 lines long and was no more functional,
beyond being more likely to break during upgrades.

I really don't see anything that can't be done with Gentoo today that
could be done if we just moved a bunch of files around.

However, if there really are things that are causing genuine problems
I'm all for making little changes that fix them when they're
practical.  My main concern with this whole area is that it really
strikes me as fighting over "the one true way."  Is there a certain
elegance to separating partition management, raid, and file storage?
Absolutely, but that doesn't mean that there aren't real benefits to
something like btrfs.

Rich

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Fri, Feb 28, 2014 at 07:09:08PM -0600, Steev Klimaszewski wrote:
> I'm not exactly a fan of systemd, though I know it has some uses, and
> I'm still curious as to why it installs/stores *configuration* data
> in /lib - if only from an upgrade point of view, we back up /etc, we
> back up /home - now we need to back up /lib, /usr/lib, /var, or whatever
> some random upstream decides is a good place to store configuration
> information!?  

Consider it default configuration information. Basically what they are
doing is, say you have a default udev rules file in
/lib/udev/rules.d/10-foobar.rules, which is provided by some package.

Now you want to override that default.

You override in /etc/udev/rules.d/10-foobar.rules instead of editing the
provided file.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Steev Klimaszewski]

On Fri, 2014-02-28 at 19:32 -0600, William Hubbs wrote:
> On Fri, Feb 28, 2014 at 07:09:08PM -0600, Steev Klimaszewski wrote:
> > I'm not exactly a fan of systemd, though I know it has some uses, and
> > I'm still curious as to why it installs/stores *configuration* data
> > in /lib - if only from an upgrade point of view, we back up /etc, we
> > back up /home - now we need to back up /lib, /usr/lib, /var, or whatever
> > some random upstream decides is a good place to store configuration
> > information!?  
> 
> Consider it default configuration information. Basically what they are
> doing is, say you have a default udev rules file in
> /lib/udev/rules.d/10-foobar.rules, which is provided by some package.
> 
> Now you want to override that default.
> 
> You override in /etc/udev/rules.d/10-foobar.rules instead of editing the
> provided file.
> 
> William

Default configuration information makes somewhat more sense - it makes a
bit more sense to store it where it has historically been, which
was /usr/share, I think anyway, rather than having to dig around the
system in arbitrary directories to find out what the default
configurations are in the first place, but who am I to judge? :)

The way that it's been presented throughout this thread made it seem
like the network configurations when using e.g. networkd were being
stored in there.  As someone who uses the bare minimum of systemd (only
to test Gnome 3.10 on ARM), it made no sense to me why it kept being
brought up that systemd kept network configuration there, I wasn't
familiar and that's why my initial response a while back asked if we
were really storing configuration information there. So thank you for
clarifying.

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Rich Freeman]

On Fri, Feb 28, 2014 at 8:57 PM, Steev Klimaszewski <steev@gentoo.org> wrote:
> The way that it's been presented throughout this thread made it seem
> like the network configurations when using e.g. networkd were being
> stored in there.

So, with the new udev what I gather is:
1.  Config settings (the stuff you're intended to change) go in /etc -
dhcp/static/whatever.
2.  Default udev rule goes into /usr.
3.  If you want to override the default persistant name rule you can
do that in /etc, but it is preferred now that you edit the config file
in /etc instead.

Where in /usr stuff goes is of course debatable.

Rich

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Joshua Kinard]

On 02/28/2014 8:28 AM, Samuli Suominen wrote:
> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, if user hasn't
> set otherwise.
> So it could be configured like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
> This would be very helpful in preventing people from shooting themself
> in the foot
> 
> The only problem is that I propably don't have enough python skills to
> make that happen w/
> sys-apps/portage. But does the suggestion make sense? Should I open a
> feature request bug?

Given the following points:

1. systemd is, for those who install it, a critical system-level component
that, when its install is damaged in some form or fashion, can make booting
very difficult (if not impossible).

2. Some users wish to explicitly override INSTALL_MASK for various reasons,
some specifically to remove systemd-related files they feel aren't needed
when they do not use this package.

3. Some profiles also override INSTALL_MASK, such as Gentoo/FreeBSD, because
systemd does not apply there.

4. So far on this thread, there are varying degrees of contention on the
correct path to take to handle this.

5. And, that Gentoo, as a whole, tries to be as flexible as possible, within
various degrees of reason.


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.

If it isn't possible to display that warning based on the specified
criteria, then I have another idea, but it's much more "hackish" in nature.
 That would be to always display the stern warning whenever any package that
installs a unit file is installed, and provide some kind of an global
environment variable that can be set in make.conf to suppress the warning.

We used to do this for glibc at one point -- I think it was for those users
who attempted to downgrade glibc.  The variable had to be defined in the
environment or in make.conf to allow emerge to downgrade glibc.  I don't
know if that var is still utilized or not.


In any event, love it or hate it, systemd is a reality and we have to
support it, along with other init systems and configurations as much as
possible (within reason).  Sam raises a good point, and I think it needs to
be addressed.  Pointing fingers and trading accusations isn't going to
accomplish anything productive.

I personally override INSTALL_MASK now for all systemd/udev folders, because
I don't use it or udev, but who knows, I might switch to it one day down the
road and forget that I have that var set.  That'll definitely cause issues
for me then, and I'll be major herp-derping when I finally remember to
delete that line from make.conf.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Joshua Kinard]

On 02/28/2014 6:14 PM, Duncan wrote:
> hasufell posted on Fri, 28 Feb 2014 16:33:43 +0000 as excerpted:
> 
>> I remember a bug report where some user was messing with INSTALL_MASK
>> and "/usr/share/locale/" and didn't notice that he effectively removed
>> all language support... and started filing random bug reports. Took
>> quite a while before someone spotted that crap in "emerge --info".
> 
> Interesting.  I have /usr/share/locale/ in my INSTALL_MASK precisely in 
> ordered to remove the language support I don't need anyway, and have had 
> it there for a very long time, with no visible ill effects.  I'd like to 
> know why someone would put a locale dir in their INSTALL_MASK in the 
> first place if they weren't purposefully trying to kill unnecessary 
> locale support...
> 
> (FWIW, I don't use a more general */locale/ mask precisely because I'm 
> not sure the global effects would be viable, tho it sure would make 
> things simpler for all the packages with their own locale dirs.)
> 

Debian has the "localepurge" package which handles removing undesired
languages from packages at install time.  Would it be possible to build an
extension to portage/paludis/pkgcore that does something similar?  Or
perhaps as an eclass that can be user-controlled based on settings in make.conf?

I've long-defined LINGUAS in my make.conf, but I forget what it was actually
used for.  An eclass/extension could pivot off of a variable like that and
remove from ${D} any non-matching locale files before merging into the live
filesystem.  That should eliminate this particular scenario.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild? Reply-To:

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

On Fri, Feb 28, 2014 at 09:06:36PM -0500, Rich Freeman wrote:
> On Fri, Feb 28, 2014 at 8:57 PM, Steev Klimaszewski <steev@gentoo.org> wrote:
> > The way that it's been presented throughout this thread made it seem
> > like the network configurations when using e.g. networkd were being
> > stored in there.
> 
> So, with the new udev what I gather is:
> 1.  Config settings (the stuff you're intended to change) go in /etc -

Correct.

> dhcp/static/whatever.

I don't know what this has to do with udev, it doesn't know anything
about dhcp/static anything.

> 2.  Default udev rule goes into /usr.

Not /usr, /lib.

Other packages that install udev rules are also putting their defaults
in there.

> 3.  If you want to override the default persistant name rule you can
> do that in /etc, but it is preferred now that you edit the config file
> in /etc instead.

I'm not following what you mean here.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Steev Klimaszewski]

On Fri, 2014-02-28 at 19:18 +0200, Samuli Suominen wrote:
> On 28/02/14 19:01, Lars Wendler wrote:
> > On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:
> >
> >> On 28/02/14 16:41, Lars Wendler wrote:
> >>> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
> >>>
> >>>> It would be very helpful if INSTALL_MASK could be overriden from an
> >>>> ebuild, if user hasn't
> >>>> set otherwise.
> >>>> So it could be configured like USE_ORDER which is
> >>>> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> >>>> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
> >>>> This would be very helpful in preventing people from shooting
> >>>> themself in the foot
> >>>>
> >>>> The only problem is that I propably don't have enough python skills
> >>>> to make that happen w/
> >>>> sys-apps/portage. But does the suggestion make sense? Should I open
> >>>> a feature request bug?
> >>>>
> >>> No need for if the ebuild(s) would use sane installation paths.
> >>>
> >>> Please finally stop imposing your insane ideas upon us, thanks.
> >>>
> >> You should stop attacking people. Period.
> > Once you stop trying to make things worse in Gentoo I will consider
> > stopping my attacks... so it's up to you.
> >
> 
> Is there anything you'd like to add before I open the comrel bug about
> baseless accusation of making things intentionally worse?
> 
> - Samuli
> 

I would like to add something - you had absolutely no problem attacking
him for putting in the work of splitting udev out to like it used to be,
but the second he says something even remotely "inciteful" (as an
innocent bystander, I didn't even understand why you felt attacked) - so
while you're opening one on him, please open one on yourself.

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Samuli Suominen]

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.

>
> 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? :-)

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Joshua Kinard]

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
kumba@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

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Dnia 2014-03-01, o godz. 07:28:35
Samuli Suominen <ssuominen@gentoo.org> napisał(a):

> 
> 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.

INSTALL_MASK is not stacked. That is, if user sets INSTALL_MASK,
profile setting gets erased.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

On 2014.02.28 14:44, Samuli Suominen wrote:
> 
> On 28/02/14 16:18, Tom Wijsman wrote:
> > On Fri, 28 Feb 2014 15:28:30 +0200
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> >
> >> It would be very helpful if INSTALL_MASK could be overriden from 
> an
> >> ebuild, ...
> > What is the intended goal? Can you give an example?
> 
> - User has INSTALL_MASK="/lib/systemd"
> - Ebuild has INSTALL_MASK_OVERRIDE="/lib/systemd/systemd-udevd
> /lib/systemd/network"
> - Portage's default is to respect ebuild first, then users setting,
> unless he changes INSTALL_MASK_ORDER to respect his
> 
> I completely agree using INSTALL_MASK is 100% responsibility of the
> user
> setting it, it's like blind 'rm -f', but some people
> don't agree and keep attacking me.
> I'm using the word attacking because it's constant, relentless,
> repeating and I don't see an end to it. I believe Poly-C just
> proofed that point in this thread.
> 
> 
> 

Samuli,

You can't win this one.  
Consider ln -s /dev/null /lib/systemd/
or whatever. It achieves the same thing and you can't override it 
unless you also remove the symlink.

INSTALL_MASK means 
I_KNOW_WHAT_IM_DOING_AND_AM_PREPARED_TO_KEEP_THE_PIECES

systemd and the components it has sucked in has become the centre of a 
religious war with Zelots on both sides.
All an INSTALL_MASK_OVERRIDE would do is escalate the war.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

28.02.2014 18:44, Samuli Suominen пишет:
> 
> On 28/02/14 16:18, Tom Wijsman wrote:
>> On Fri, 28 Feb 2014 15:28:30 +0200
>> Samuli Suominen <ssuominen@gentoo.org> wrote:
>>
>>> It would be very helpful if INSTALL_MASK could be overriden from an
>>> ebuild, ...
>> What is the intended goal? Can you give an example?
> 
> - User has INSTALL_MASK="/lib/systemd"
> - Ebuild has INSTALL_MASK_OVERRIDE="/lib/systemd/systemd-udevd
> /lib/systemd/network"
> - Portage's default is to respect ebuild first, then users setting,
> unless he changes INSTALL_MASK_ORDER to respect his
> 
> I completely agree using INSTALL_MASK is 100% responsibility of the user
> setting it, it's like blind 'rm -f', but some people
> don't agree and keep attacking me.
> I'm using the word attacking because it's constant, relentless,
> repeating and I don't see an end to it. I believe Poly-C just
> proofed that point in this thread.
> 

If the user set INSTALL_MASK improperly than he(read as 'He, NOT package
maintainer') should fix the stuff if it will break.

We allow user's to update glibc if they accidently set
ACCEPT_KEYWORDS=~arch(even if downgrading it is really PITA), why we
should behave differently here?

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

On Fri 28 Feb 2014 15:28:30 Samuli Suominen wrote:
> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, if user hasn't set otherwise.

i don't see this happening as it makes no sense.  you INSTALL_MASK something 
dumb then that's your fault.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Steven J. Long]

Joshua Kinard wrote:
> 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.

No, it makes a lot of sense. Though you don't use parentheses or commas
in bash ;)

I'd use something like:
# echeck_warn -s : INSTALL_MASK /usr/lib/systemd
echeck_warn(){
	echeck_var warn "$@"
}

echeck_error(){
	echeck_var error "$@"
}

echeck_var(){
	local v n i f x r=0 s=' '
	case $1 in
	warn) f=ewarn
;;	error) f=eerror
;;	*) die "bad use of: '$FUNCNAME $*'"
	esac
	shift
	[[ $1 = -s ]] && {
		s=$2; shift 2;
		# handle PATH style
		[[ $s = : ]] && x='/*'
	}
	v="$s${!1}$s" || die "bad var: $1"
	n=$1
	shift
	for i; do
		if [[ $v = *"$s$i$s"* ]]; then
			:
		elif [[ $x ]]; then
			if [[ $v = *"$s$i$x$s"* ]]; then
				:
			elif [[ $i = */ ]] && [[ $v = *"$s$i*$s"* ]]; then
				:
			else continue
			fi
		else continue
		fi
		"$f" "$n contains: '$i'"
		r=1
	done
	if ((r)) && [[ $f = eerror ]]; then
		die "Bad $n"
	else
		return $r
	fi
}

eg:
$ INSTALL_MASK='/lib/udev/*:/usr/lib/systemd/*'
$ echeck_error -s : INSTALL_MASK /lib/udev /usr/lib/systemd/
!! INSTALL_MASK contains: '/lib/udev'
!! INSTALL_MASK contains: '/usr/lib/systemd/'
!! die: Bad INSTALL_MASK

You'd replace literal * in: [[ $v = *"$s$i*$s"* ]] with: ${x#/}
for something more complex. And you might prefer simple return
and use echeck_error .. || die ..
HTH as a start.

Regards,
steveL
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Samuli Suominen]

On 22/03/14 08:13, Mike Frysinger wrote:
> On Fri 28 Feb 2014 15:28:30 Samuli Suominen wrote:
>> It would be very helpful if INSTALL_MASK could be overriden from an
>> ebuild, if user hasn't set otherwise.
> i don't see this happening as it makes no sense.  you INSTALL_MASK something 
> dumb then that's your fault.
> -mike

agreed. 

honestly, I agreed the whole time -- was just trying to satisfy group of
loud people, and now I have this ML thread I can point them to, which is
enough

Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Tom Wijsman]

On Wed, 26 Mar 2014 13:27:52 +0000
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> eg:
> $ INSTALL_MASK='/lib/udev/*:/usr/lib/systemd/*'
> $ echeck_error -s : INSTALL_MASK /lib/udev /usr/lib/systemd/
> !! INSTALL_MASK contains: '/lib/udev'
> !! INSTALL_MASK contains: '/usr/lib/systemd/'
> !! die: Bad INSTALL_MASK

If we were to take this example to its extreme; then we would have to
create an inventory of which INSTALL_MASK entries are good and bad for
each ebuild, in which we cover all the files installed by that ebuild.

People that use INSTALL_MASK should be very well aware of what they are
doing, as with any other variable or command you run you need to be
very aware of what it does; that you mask installation of /lib/udev/
and /usr/lib/systemd/ therefore would be based on their knowledge of
what is in these directories, and not on our hand holding thereof.

Reminds me about my INSTALL_MASK on configure* and Makefile*; by doing
so, I missed out on packages installing these for use in rev dep builds.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Anthony G. Basile]

On 03/26/2014 09:32 AM, Samuli Suominen wrote:
> On 22/03/14 08:13, Mike Frysinger wrote:
>> On Fri 28 Feb 2014 15:28:30 Samuli Suominen wrote:
>>> It would be very helpful if INSTALL_MASK could be overriden from an
>>> ebuild, if user hasn't set otherwise.
>> i don't see this happening as it makes no sense.  you INSTALL_MASK something
>> dumb then that's your fault.
>> -mike
> agreed.
>
> honestly, I agreed the whole time -- was just trying to satisfy group of
> loud people, and now I have this ML thread I can point them to, which is
> enough
>

I'm with Mike here.  Let's not complicate this option.  If someone does 
and INSTALL_MASK then they are doing it for a a reason and they should 
know what they are doing.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Steven J. Long]

Tom Wijsman wrote:
> If we were to take this example to its extreme; then we would have to
> create an inventory of which INSTALL_MASK entries are good and bad for
> each ebuild, in which we cover all the files installed by that ebuild.

Why are you directing this at me? Please don't cc me off-list. Keep list
discussion to the list. (That's an old one.)

As for "extremes" I think it a dubious argument, much like many of your
"if only we define X like Y, even though we've all been discussing X" at
the end of a long chain of usually futile "discussion". It's evidently
meant for a few packages which would break, to avoid obvious breakage,
and not as a blanket mechanism. That would run counter to the whole
spirit of "you break it, you pick up the pieces." IF there is a need to
do it, that's how you can do it.

If not, it's got nothing to do with me anyhow, since I'm not the one
calling for it, nor raising the topic.

Oh, and I realise you have difficulty configuring your email client[1]:
it's still rude of you to constantly quote people's email addresses
inline, imo. Long, tedious "justifications" notwithstanding.
Especially when it turns out you can't even configure your client,
and it might reasonably be surmised you have spouted "justification"
to cover ignorance. I'm perfectly happy to take the time to edit my
responses, in answer to your last justification for this behaviour.

[1] http://marc.info/?l=gentoo-user&m=139549986219431&w=2
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Tom Wijsman]

On Thu, 27 Mar 2014 13:43:24 +0000
"Steven J. Long" wrote:

> Tom Wijsman wrote:
> It's evidently meant for a few packages which would break, to avoid
> obvious breakage, and not as a blanket mechanism.

Yes, it is; but a package consists of multiple ebuilds, and thus, the
individual files of the individual ebuilds are brought up as they
would need to be tracked, which brings in more work to the maintainer.

--
[OT] Below talk is about whom is addressed & gentoo-dev ML etiquette.

> > If we were to take this example to its extreme; then we would have
> > to create an inventory of which INSTALL_MASK entries are good and
> > bad for each ebuild, in which we cover all the files installed by
> > that ebuild.
> 
> Why are you directing this at me?

The quoted paragraph is directed at anyone reading the example; and
given I direct it to them, you are directed to as part of this out
of respect to allow you to update the example if you need to.

> it's still rude of you to constantly quote people's email addresses

Why is it rude? There are a lot of other developers on the list here
that do this as well; so, if you want to see this changed then please
bring it up for a vote. Un-CC-ed and stripped this time per request;
being able to set this on a specific person, however, I don't see how
to do that in my mailing client. Patches to do as such are welcome.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Joshua Kinard]

On 03/27/2014 18:26, Tom Wijsman wrote:
> On Thu, 27 Mar 2014 13:43:24 +0000
> "Steven J. Long" wrote:
>> it's still rude of you to constantly quote people's email addresses
> 
> Why is it rude? There are a lot of other developers on the list here
> that do this as well; so, if you want to see this changed then please
> bring it up for a vote. Un-CC-ed and stripped this time per request;
> being able to set this on a specific person, however, I don't see how
> to do that in my mailing client. Patches to do as such are welcome.

I think this is more a function of the mail client, not individual people's
preferences.  I could've swore that Thunderbird, would use the following format:

"On <DATE> <TIME>, <NAME> <<EMAIL>> wrote:"

But now, it looks like Thunderbird drops the <<EMAIL>> portion.  Must've
been a change in 17.x?

IMHO, trying to hide one's e-mail, especially on a rather large, well-known,
open-source project is an exercise in futility.  I quote mine in my sig at
the bottom, it's in my PGP key, stored in the Changelogs I've touched over
the last decade, probably still in a few of the documentation pages on the
Gentoo website, and easily derivable from my known username and the Gentoo
domain name.

So, whatever floats people's shredded wheat, but I wouldn't worry about it.
 If a spambot really wants your e-mail, it's going to find it and send you
free medical prescriptions or inform you of lost rich relatives in Nigeria,
whether you like it or not.  If blame has to be assigned, blame the
underlying protocol(s).  The fact that 21st century global business runs on
top of antiquated, ASCII-based, non-secure protocols developed in the 1970's
simply floors me.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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