[gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
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?
On Fri, 28 Feb 2014 15:28:30 +0200
Samuli Suominen ssuomi...@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 : tom...@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?
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?
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
signature.asc
Description: PGP signature
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
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?
On 28/02/14 16:18, Tom Wijsman wrote: On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen ssuomi...@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?
-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?
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?
-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?
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: bluen...@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?
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?
On Fri, Feb 28, 2014 at 9:44 AM, Samuli Suominen ssuomi...@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
[gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Samuli Suominen: On 28/02/14 13:15, Patrick Lauer wrote: On 02/27/2014 09:08 PM, Anthony G. Basile wrote: Hi everyone, I'm putting the call out there for any agenda items for the next Council meeting, which will be held on March 11, 2014 at 1900 UTC. This is short notice but we got off track because of FOSDEM and we're going to try to get back on track. So far, the only item is final ratification of glep 63 [1]. Since it's still a bit cold I'd like to start a nice fire to warm us up: I'd like QA and Council to figure out how much we care about FHS. My main complaint is some projects (including e.g. systemd and apparently now also udev) storing config files in /lib and/or /usr/lib. From FHS' point of view this is totally wrong, config files go to /etc Only libraries should be in /lib. Wow. What about libtool .la text files? What about kernel modules? What about the genereted modules.* data in /lib/modules/$version/ which are used in early boot by eg. kmod-static-nodes? What about the binaries of OpenRC in /lib/rc, they aren't libraries? And what about vendor modprobe.d files in /lib/modprobe.d? I could continue this all day. I'm just trying to point out Only libraries should be in /lib. is complete bs and does not work. Does FHS really articulate it the way you said it, Only libraries should be in /lib. or was that your own interpretation of it? I'm not really expecting an answer as I'm already convinced FHS is so badly outdated it's sad it doesn't suit modern systems. I hope they will catch up at some point. - Samuli In addition to the questions of Samuli... What about python, perl, ruby and whatnot script languages. What about haskell and pascal? Some of them files are reported to be data files. What about erlangs .erl and .hrl (text)? What about mono/C# .exe and .dll (are they architecture-dependant or can I treat them as data files and move them to /usr/share/?) What about non-trivial packages like fpc, firefox, portage and libreoffice that all violate FHS? Who will fix it and maintain that stuff downstream? What about /opt, we don't follow that either? What about /usr/include and .hpp files (only C is valid according to FHS)? Who will fix boost? I skip the part of running some funny find commands on my local system. Despite that... the answer is already here: http://devmanual.gentoo.org/general-concepts/filesystem/index.html Gentoo does not consider the Filesystem Hierarchy Standard to be an authoritative standard, although much of our policy coincides with it. So this is not really something the council has to decide on, unless you propose to change that policy altogether. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTELJnAAoJEFpvPKfnPDWzjGwIAK1rEmYgKodNs4OT1cHJWinA A+cWLepzDPMRKr7cPtt6UCYsZP1hidYW/vIrTTI8XynYEkTsSNaawtk6JJLN6qAD 8E0TXZJN8flH5nu7rBVaxJ1liEAEy/qmYMqs5wfI64sYoqOuIiScpk/CjWPMoGob 7UZuxbBhJGnt+/VsgVeor1GZM+dQ2ygBnp9g9A7QjfsIpBitGjSQvYet9z1O01OP T/SXPiti/yTbz3Au17GLaxQrbK9Kp6Qi676B544S1z9wkXClXJiWV8yD2BcfcX9T GmfqKNb3Mna2qyLIpZ96nDy28eJpvEA6X72lRpPhJqMEHr+1+vqQQn5Uc8F+4ak= =gGfE -END PGP SIGNATURE-
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
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?
-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?
-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?
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
signature.asc
Description: PGP signature
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
-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?
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
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Fri, Feb 28, 2014 at 10:59 AM, hasufell hasuf...@gentoo.org wrote: Despite that... the answer is already here: http://devmanual.gentoo.org/general-concepts/filesystem/index.html Gentoo does not consider the Filesystem Hierarchy Standard to be an authoritative standard, although much of our policy coincides with it. So this is not really something the council has to decide on, unless you propose to change that policy altogether. As far as what the new policy should be goes, a lot has developed in the linux world post-FHS. The biggest one is the whole /usr-move direction that many distros seem to generally be moving in. Vertical integration complements this (making booting without /usr a challenge). Initramfs has also come along and has basically turned into a userspace bootloader of sorts. The whole config-files-in-/usr thing is also driven by this, and also by the desire of distros to avoid something like etc-update. We do the same thing with make.defaults, which doesn't go in etc (though to be fair it is linked from there, sort-of). The general direction of projects like systemd, the /usr-move, config files in /usr, and so on fix real problems on most distros. I think one of the challenges for Gentoo is that many of these problems are ones that Gentoo has already fixed, somewhat. So, for us it isn't about moving from a gaping hole into a workable solution, but moving from one solution we're already accustomed to into another new solution that might or might not be somewhat better, and which likely involves some tradeoffs. For anybody using a non-dependency-aware service manager systemd is a huge improvement, for an openrc user the benefits really aren't that dramatic, though I suspect for laptop users it could be a step up once it matures. Gentoo is also not release-oriented, so the /usr-move doesn't really carry the same benefits. If you are release-oriented and have completed the /usr-move then upgrading your distro might be equivalent to symlinking /usr to a zero-seek-time CD drive, and swapping out the disc, kernel, and initramfs. I think the real issue for Gentoo is the cost of doing things differently. Right now we're just looking at that in terms of how hard it is to stick a doins in an ebuild, but that is just the starting point. Once you start getting vertical integration then you run into a myriad of things being done differently vs upstream, and that can snowball. You have to ask what we're getting for all of that. Is the world a better place if Gentoo sticks config defaults in /etc/default vs wherever upstream puts them? Is there value in having those defaults clogging your /etc scm or whatever you're using to manage config, when it is already managed by your package manager? I'm all for an evolution of FHS that helps address some of these questions, but that really isn't something we can do at the distro level. It would take working WITH all of those newfangled projects that are doing things that annoy us, finding ways to standardize across distros while still giving the binary distros what they need. A distro like Ubuntu isn't going to buy into the concept that etc-update makes their problems moot. I think Gentoo needs to stick to being different where being different really adds value. That means rolling releases, flexibility around dependency versioning, control over build-time options, flexibility around system components whenever practical, and so on. We can't really afford to fight WW3 over where some config file gets installed, or what its filename is. We can't afford to build a Gnome3 that works without systemd (at least, not for long), and so on. What we can do is support any forks/clones/etc that have a sustainable community around them (such as eudev, openrc, etc). Finally, this is a volunteer distro - contributions get you a lot further than criticism. So, publish all the forks/overlays/alternates/etc you want, and by all means solicit support for them. Once upon a time few ebuilds had systemd units, looking at the tracker now that is mostly limited to packages that I've never heard of. All it takes for an option to remain viable is a few people who care enough to steadily contribute. Rich
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Fri, Feb 28, 2014 at 03:59:35PM +, hasufell wrote: *snip* Despite that... the answer is already here: http://devmanual.gentoo.org/general-concepts/filesystem/index.html Gentoo does not consider the Filesystem Hierarchy Standard to be an authoritative standard, although much of our policy coincides with it. So this is not really something the council has to decide on, unless you propose to change that policy altogether. Agreed. Gentoo has never considered the fhs to be authoritative. It is a guide. If we can follow it we do, if we can't we don't. There is nothing to change here unless you are asking that we make fhs authoritative, which I would be firmly against. Regarding the comments blueness made on -project about the /-/usr merge violating fhs, I have spoken with vapier about this myself on several occasions, and his position is exactly the opposite; it does not violate fhs. You might also want to read this article on osnews about why the split happened; there is definitely interesting information here [1]. The reason the split happened is pretty straight forward, and every other justification for continuing it was come up with after the fact. William [1] http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split/ signature.asc Description: Digital signature
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
William Hubbs wrote: The reason the split happened is pretty straight forward, and every other justification for continuing it was come up with after the fact. I keep hearing this, but I really don't see how it's relevant. I'm sure you'll find lots of things in your life that you use for some purpose other than what they were originally invented for¹, and there's no reason why /usr should be any different. All that matters is whether or not the newer reasons for having separate /usr actually provide a benefit. [1] http://en.wikipedia.org/wiki/Coca-Cola#19th_century_historical_origins
[gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?
hasufell posted on Fri, 28 Feb 2014 16:33:43 + 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?
Dnia 2014-02-28, o godz. 15:28:30
Samuli Suominen ssuomi...@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
signature.asc
Description: PGP signature
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote: William Hubbs wrote: The reason the split happened is pretty straight forward, and every other justification for continuing it was come up with after the fact. I keep hearing this, but I really don't see how it's relevant. I'm sure you'll find lots of things in your life that you use for some purpose other than what they were originally invented for¹, and there's no reason why /usr should be any different. All that matters is whether or not the newer reasons for having separate /usr actually provide a benefit. And I would argue that the maintenance cost of having separate /usr in a general sense is much higher than the benefit it provides. The problem with it is that it is next to impossible nowadays to define what should go in / vs what should go in /usr. William signature.asc Description: Digital signature
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs willi...@gentoo.org wrote: On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote: William Hubbs wrote: The reason the split happened is pretty straight forward, and every other justification for continuing it was come up with after the fact. I keep hearing this, but I really don't see how it's relevant. I'm sure you'll find lots of things in your life that you use for some purpose other than what they were originally invented for¹, and there's no reason why /usr should be any different. All that matters is whether or not the newer reasons for having separate /usr actually provide a benefit. And I would argue that the maintenance cost of having separate /usr in a general sense is much higher than the benefit it provides. The problem with it is that it is next to impossible nowadays to define what should go in / vs what should go in /usr. William Now it is difficult as too much time it was ignored. In the past it was quite simple, everything that requires a server to reach default runlevel. The problem is that instead of telling users: If you are using special user mode devices, such as bluetooth keyboards, please make sure /usr is mounted at boot, we enforce all that configuration, so now initramfs should contain all that once was / with much harder maintenance. Alon
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
William Hubbs wrote: And I would argue that the maintenance cost of having separate /usr in a general sense is much higher than the benefit it provides. That's a legitimate point (not that I necessarily agree or disagree as I'm not the one who's tried to make it work) - perhaps I should have acknowledged that it's still a trade-off. I'm just trying to get rid of the meme that whatever benefits do exist somehow don't count because they weren't planned in the original Unix design.
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 01, 2014 at 12:24:02AM +, David Leverton wrote: William Hubbs wrote: And I would argue that the maintenance cost of having separate /usr in a general sense is much higher than the benefit it provides. That's a legitimate point (not that I necessarily agree or disagree as I'm not the one who's tried to make it work) - perhaps I should have acknowledged that it's still a trade-off. I'm just trying to get rid of the meme that whatever benefits do exist somehow don't count because they weren't planned in the original Unix design. Actually we are digressing heavily (I'm guilty too), the original point of this thread was about the fhs and how tightly we are supposed to follow it. Patrick thinks that all configuration files belong in /etc, and what has happened is, some packages are placing default configuration files in /lib or /usr/lib and allowing them to be overridden by files with the exact same names and paths in /etc. His argument is that only libraries belong in /lib or /usr/lib. I disagree with this based on understanding how the config system in these packages works. Also, I don't think a distro should do this type of patching if the patches are not accepted upstream. William signature.asc Description: Digital signature
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
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?
On Fri, Feb 28, 2014 at 8:09 PM, Steev Klimaszewski st...@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?
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 signature.asc Description: Digital signature
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
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?
On Fri, Feb 28, 2014 at 8:57 PM, Steev Klimaszewski st...@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] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Fri, Feb 28, 2014 at 7:47 PM, William Hubbs willi...@gentoo.org wrote: Patrick thinks that all configuration files belong in /etc, and what has happened is, some packages are placing default configuration files in /lib or /usr/lib and allowing them to be overridden by files with the exact same names and paths in /etc. His argument is that only libraries belong in /lib or /usr/lib. I didn't get that vibe from what was quoted in OP. Maybe there's something missing. But let's be real here: if I install something and want to configure its system-wide bits, the first place I go is ALWAYS /etc. When I don't find it there, with the rest of the system config files, my day gets a little worse and I lose a bit of time trying to interrogate a search engine for the answer. And that's annoying. That sucks. I don't particularly care about the history, or the politics, or what upstreams think they have the right to decide for me. Sure, it might be only convention, but even then it's still valuable by merit of allowing you to make (often correct) predictions about where to configure your shiny new daemon and by reducing cognitive load (no need to remember that Okay, so bonehead has its config in /usr/lib/bone/head/ and sillyd has it's config in /var/silly/comedy/, and...where was riced.conf, again?). I disagree with this based on understanding how the config system in these packages works. Also, I don't think a distro should do this type of patching if the patches are not accepted upstream. I somehow get the sense that you're talking about specific packages, but more generally: If there's some legitimate reason the config can't go where configs...go (like the package hardcoding the path to the config without any overrides possible (which sounds absolutely moronic, IMO. What if you want to temporarily test a new config?)) then sure, let it live where it lives. But for stuff where they're already able to be overridden by a version in /etc anyway? I don't think if users are supposed to be able to modify it, the config should be /etc is an unreasonable position to take. Reducing user pain isn't an all-or-nothing exercise. Cheers, Wyatt
Re: [gentoo-dev] Enabling EAPI 5 in arch profile directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2013 06:43 PM, Andreas K. Huettel wrote: Am Dienstag, 31. Dezember 2013, 23:30:14 schrieb Mike Gilbert: I have noticed that the arch profile directories (profiles/arch/$ARCH) are not EAPI 5 capable. These profiles are inherited by both the default and hardened profiles and contain arch-specific settings. They are often used to override masks set in the base profile. [...] Here are a couple of alternatives: 1. Add profiles/eapi-5-files/$ARCH. 2. Add profiles/$ARCH/eapi-5-files. Here's option 3: In a few days the one year waiting time after making EAPI5 profiles the default is over, and (pending revisit by the council and agreement) the whole profiles tree can be switched to EAPI5. This means the files from the eapi-5-files directory move to a more central location and the eapi-5-files directory can be removed. With that change the arch dirs automatically also become EAPI5 capable if done properly. See also http://www.gentoo.org/proj/en/council/meeting-logs/20130108-summary.txt Best a happy new year, Andreas To ease this transition, I've drafted a news item based on info from zmedico's blog about when eapi 5 was first supported. This is, in my eyes, the simplest way to transition users who may be on really, really, really outdated systems. It occurred to me I could make a minimal snapshot instead, but it seems much much safer to do this for now. Please review the news article. Thanks! Zero_Chaos PS You can skip review of the body line lengths, I will adjust them to spec (72) as needed after the review, any and all current linewrap is from my email client. - -- Title: Profile EAPI 5 requirement Author: Zero_Chaos zeroch...@gentoo.org Content-Type: text/plain Posted: 2014-03-02 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: 2.2.0_alpha130 In its last session, the Gentoo council decided that the entire profile tree will be updated to require EAPI=5 support. http://www.gentoo.org/proj/en/council/meeting-logs/20140114.txt For all non-deprecated profiles this requirement has already been in place for over one year. If you have updated your system at any point during 2013, and followed the instructions in the profile deprecation warnings (which cannot really easily be overlooked), and are running an up-to-date portage version, there is absolutely nothing that you need to do now. If you are running an installation that has not been updated for more than a year, the portage tree you have just updated to is may be incompatible with your portage version, and the profile you are using may be gone. It is still possible to upgrade, if you follow these simple steps: 1.) Do not panic. 2.) Download a portage snapshot from http://dev.gentoo.org/~zerochaos/snapshots 3.) Unpack the snapshot to /tmp/ 4.) If you are not already, become root 5.) rsync --recursive --links --safe-links --perms --times --force - --whole-file --delete --stats --human-readable --exclude=/distfiles - --exclude=/local --exclude=/packages --verbose --progress - --omit-dir-times /tmp/portage /usr/portage 6.) If needed, set your profile to a modern one (typically named 13.0) 7.) emerge --update --oneshot portage Now that you have a modern copy of portage, you can go back to updating your system as usual. Please update your system at LEAST twice a year to avoid issues like this in the future. Thanks for flying Gentoo. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTEUvEAAoJEKXdFCfdEflK5lAP/RTivl0QjlB2kyWZbtVIURMR X6ELgIkBggrgYvwMqBdz8JG+YFc4Q0gi2xDz9QE+13ysUYCFUmibbasukb2WiVtA zNyoNHxoZQEmBuKzDNg3QzkcVsxD+SQ97fq3r2iRYN6tVXbDn5r+i4kCLivDws7y Knc3ankf9ShrY3qjJdH3M1xe4kRyX8RBeq2/5kvl43TLu1T3zLJ4bY+RlOX1lOJC MB01akcJ45gbJ1bAYrT0nN2Q0HC40tKV4I3uNFcllEkjOkv4vmMSQR2ZrcTo+f5C cAaiHTO4zDeHEKmmtI9j/t2ui3GVbelnooFPuH/6IS5NNmkILIo3a3UQsXgugzJX 7seAaGVzoxgMRUHoA9On5M1FWCFf6Z+JE/PbaJMhZUePVcivgGT8RvmnkSsIexHZ 4tjVlIjjULFLDz6i229K+RtmsO7b3EV+RXNw6hO8UIjz65QevZ84aNib8ipGJ+Lm b7xOCjIS7yNZAtb91PWiE/PoZC0MilAC2xBE6ex/dX1qZPCLpvCPTgQ7hu83GEBX h9gqYbMuL/Q+mHG/4PwKppMMmx///Hs/aowLRUGJdN61rxBu6VD69Shnxy3N4OO1 pTviiPh0xvv0HSHd61mX/8cdx7GEn39oyd3inwShFvE6cwtn1QqgbS0MZeMqQVX+ Ih3725/4uXsyM9NS0q3r =prsT -END PGP SIGNATURE-
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
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
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
Re: [gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?
On 02/28/2014 6:14 PM, Duncan wrote:
hasufell posted on Fri, 28 Feb 2014 16:33:43 + 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
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
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild? Reply-To:
On Fri, Feb 28, 2014 at 09:06:36PM -0500, Rich Freeman wrote: On Fri, Feb 28, 2014 at 8:57 PM, Steev Klimaszewski st...@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 signature.asc Description: Digital signature
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote: On Fri, Feb 28, 2014 at 7:47 PM, William Hubbs willi...@gentoo.org wrote: Patrick thinks that all configuration files belong in /etc, and what has happened is, some packages are placing default configuration files in /lib or /usr/lib and allowing them to be overridden by files with the exact same names and paths in /etc. His argument is that only libraries belong in /lib or /usr/lib. I didn't get that vibe from what was quoted in OP. Maybe there's something missing. But let's be real here: if I install something and want to configure its system-wide bits, the first place I go is ALWAYS /etc. When I don't find it there, with the rest of the system config files, my day gets a little worse and I lose a bit of time trying to interrogate a search engine for the answer. And that's annoying. That sucks. This hasn't changed. The configuration files these packages are putting in /lib are not meant to be edited; they are the package provided defaults. If you want to override one of them, you do that in a file with the same path and name in /etc, like I mentioned in another message in this thread. William signature.asc Description: Digital signature
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
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] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On 02/28/2014 7:47 PM, William Hubbs wrote: On Sat, Mar 01, 2014 at 12:24:02AM +, David Leverton wrote: William Hubbs wrote: And I would argue that the maintenance cost of having separate /usr in a general sense is much higher than the benefit it provides. That's a legitimate point (not that I necessarily agree or disagree as I'm not the one who's tried to make it work) - perhaps I should have acknowledged that it's still a trade-off. I'm just trying to get rid of the meme that whatever benefits do exist somehow don't count because they weren't planned in the original Unix design. Actually we are digressing heavily (I'm guilty too), the original point of this thread was about the fhs and how tightly we are supposed to follow it. Patrick thinks that all configuration files belong in /etc, and what has happened is, some packages are placing default configuration files in /lib or /usr/lib and allowing them to be overridden by files with the exact same names and paths in /etc. His argument is that only libraries belong in /lib or /usr/lib. I disagree with this based on understanding how the config system in these packages works. Also, I don't think a distro should do this type of patching if the patches are not accepted upstream. Digressing a little myself, but trying to remain on point, the _only_ reason I went with a split-/usr setup many years ago is because, back in the early 2000's, BOTH Debian's Security Handbook AND Gentoo's Security Handbook recommended it as an option to enhance system security should all your other defenses get compromised and an attacker gets onto the filesystem. Does it completely and utterly stop all lateral movement? Nope. Probably takes a seasoned attacker all of 2-3mins to get around it. That setup has run great for years. I rarely re-install entire OSes, too, preferring to maintain and upgrade them. I.e., one of my Windows installs is over five years old, having started w/ Vista SP1 and now it's on Win7 SP1. Most people reinstall Windows twice a year because it can become cluttered up so quickly. So when that Freedesktop.org page came out a few years ago and suddenly declared that split-/usr was broken, I just felt snubbed by it. I had 7-year old installs that booted just fine. Who were these freedesktop.org people that were dictating that my particular setup was suddenly broken? Call it a case of having my geek pride insulted. Like hell I was going to change. But, you know, in reality, they had a point. Original System V UNIX did a lot of weird things that probably made sense decades ago, but don't now. You find this virtually endemic across a lot of OSes, too: - Windows is happy to let you dribble non-OS related files all over C: (which makes backups and OS re-installs a lot of fun) -- this was fine in Win95/Win98, but became more of an issue in XP and up. Nowadays, people usually install the OS to C: and put games/programs on a separate drive entirely. - NetWare seems to roll dice when installing things into the SYS: volume. Some configs are in SYS:\SYSTEM\ETC, Apache lives in SYS:\APACHE2\, and a lot of other bits are encoded into eDirectory attributes (DNS/DHCP configs). - The *BSDs make heavy use of /usr/local for things that can confuse non-BSD users (at first). Even the install locations of Ports varies across the BSDs (FBSD has /usr/ports, DF/BSD has /usr/dports, NBSD has pkgsrc, etc). Anyways, back on point, FHS is more-or-less deprecated. It was reasonable when Linux had a small ecosystem. Now, Linux has a *huge* ecosystem that it operates in. Everything from small, embedded devices to multi-node supercomputing clusters, to servers and desktops. FHS does doesn't scale well to all of those configurations. Android pretty much ignores FHS, from what I can tell. Options really are boiled down to these three: 1. Continue to support FHS as much as possible, including patching upstream packages when they violate FHS. 2. Ignore FHS entirely and let upstream packages do what they want, within reason (i.e., some patching may be needed depending on if one was running Gentoo/Linux or Gentoo/FreeBSD). 3. Develop our own, Gentoo-specific variant of FHS that we use and which suits the particulars of our distribution in a way that we feel is sensible (my choice). Packages are patched as appropriate, after discussion/debate. For all we know, the way an upstream package does something by default might be worth integrating into our FHS design. Further on point #3, we'd have to probably develop a high-level, kernel-agnostic layout that can be modified by kernel-specific differences. I.e., Gentoo/Linux is going to do things one way while Gentoo/FreeBSD is going to do it a different way. Ditto for Hardened or Embedded stuff. -- 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
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On 01/03/14 02:18, Alon Bar-Lev wrote: On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs willi...@gentoo.org wrote: On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote: William Hubbs wrote: The reason the split happened is pretty straight forward, and every other justification for continuing it was come up with after the fact. I keep hearing this, but I really don't see how it's relevant. I'm sure you'll find lots of things in your life that you use for some purpose other than what they were originally invented for¹, and there's no reason why /usr should be any different. All that matters is whether or not the newer reasons for having separate /usr actually provide a benefit. And I would argue that the maintenance cost of having separate /usr in a general sense is much higher than the benefit it provides. The problem with it is that it is next to impossible nowadays to define what should go in / vs what should go in /usr. William Now it is difficult as too much time it was ignored. Nod If only Portage had supported checking if files from /usr were used by files installed to / Hard to create check for every case, but something like libraries and NEEDED entries (bug 443590) would have been a start But there simply wasn't enough popular demand for sep. /usr, so nobody was willing to do the work
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
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?
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
[gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 01, 2014 at 07:20:24AM +0200, Samuli Suominen wrote: If only Portage had supported checking if files from /usr were used by files installed to / Hard to create check for every case, but something like libraries and NEEDED entries (bug 443590) would have been a start But there simply wasn't enough popular demand for sep. /usr, so nobody was willing to do the work Actually when I proposed working on exactly that (twice), for both initramfs and traditional usr setups, you and mgorny shouted me down, diverting it into a discussion about how I was a hater for not seeing why I should change anything on my systems. That's why there was no demand: every halfway-sane proposal at collaboration was turned into an insane argument. No-one with any self-respect would want to collaborate with people who treat them like that. Neat bit of revisionism though; I almost thought you cared about us old fusties for a moment there. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote: On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote: But let's be real here: if I install something and want to configure its system-wide bits, the first place I go is ALWAYS /etc. When I don't find it there, with the rest of the system config files, my day gets a little worse and I lose a bit of time trying to interrogate a search engine for the answer. And that's annoying. That sucks. This hasn't changed. The configuration files these packages are putting in /lib are not meant to be edited; they are the package provided defaults. If you want to override one of them, you do that in a file with the same path and name in /etc, like I mentioned in another message in this thread. The problem, as has been explained many many times, is that the rest of the config is somewhere random on the system. But you knew that, right? You were just telling a half-truth, effectively. I for one prefer a distro to do a bit of work and make my life easier, since it makes life easier for everyone who uses the distro. Why the hell should I care if some bindist can't etc-update? WTF does that have to do with Gentoo? If I wanted a shitty distro that didn't bother to do anything at all, I'd use LFS. At least they don't pretend, then fall over themselves to do a crap load of work rather than admit a mistake; that hey, y'know what? Some of those things from 30 years ago were a damn good idea, and maybe just maybe, they worked some of these issues out back then, so we could stand on their shoulders instead of digging through their garbage. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On 01/03/14 08:40, Steven J. Long wrote:
On Sat, Mar 01, 2014 at 07:20:24AM +0200, Samuli Suominen wrote:
If only Portage had supported checking if files from /usr were used by
files installed to /
Hard to create check for every case, but something like libraries and NEEDED
entries (bug 443590) would have been a start
But there simply wasn't enough popular demand for sep. /usr, so nobody
was willing to do the work
Actually when I proposed working on exactly that (twice), for both initramfs
and traditional usr setups, you and mgorny shouted me down, diverting it into
a discussion about how I was a hater for not seeing why I should change
anything on my systems.
I don't remember anything of that sort. I may have overlooked at
your suggestion and replied to other part of your post, but I certainly
haven't said such checks would be a bad idea.
I don't appericiate the twisting of history.
Neat bit of revisionism though; I almost thought you cared about us old
fusties for a moment there.
I don't appericiate the attempt of trying to categorize me into one
of these pro-, anti-, {systemd,udev,eudev,sep. /usr,whatever} camps.
I wonder, did you notice who filed bug 443590 to begin with?
- Samuli
