Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
/usr/lib/modules-load.d systemd affecting openrc
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sat Jul 29, 2017 12:55 pm    Post subject: Reply with quote

josephg wrote:
i thought the USE=systemd was for this very reason.. ie to add/remove any systemd stuff (files/locations/behaviour).

The purpose of USE flags is explicitly not to prevent installation of small files. Their purpose is limited to installation of large files (or with a side effect), severe dependencies, or when the compiled binary is affected (e.g. because it links to some library or not).
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6855

PostPosted: Sat Jul 29, 2017 1:20 pm    Post subject: Reply with quote

mv wrote:
@krinn: You have to see it from the viewpoint of developers who write a general package

No i have to see it like it need to be seen: from the point of the view of the user, or the sysadmin
It's because they seeing it from dev pov that this fail: oh my users are dumb ass and they will complains virtualbox doesn't work because they forget or are too dumb to load the modules: i will force these modules load for them then.

mv wrote:
This is a sane standard and has nothing to do with systemd.

This is a systemd directory location, so it's totally related to systemd ; it's even more related to systemd because openrc already have module handling, you don't took and create a feature from systemd in openrc to enhance openrc, you duplicate a feature you already have there.
This is in no way a standard, it's not because you (in this case pottering) decide that your modules will be put in "somewhere" that "somewhere" is a standard.
If there's no standard, the per default assumption is that previous usage is the standard, and systemd is the most recent init ; so you can count any others as standard.
So you can claim it's standard for systemd but in no way claim it's standard ; sorry i'm not drinking that.
Can we keep this topic out of false argument for systemd supremacy? we have politics of systemd thread for that.

It's also totally related to systemd as my hostility to systemd made you assume i was hostile there "because it's related to systemd".
I'm hostile there, because dev put files in it when you didn't ask him to do so ; and because this could have an impact: i didn't test, but i'm pretty sure my system will be broken by such action, nvidia drivers is well known to hate any other drivers using the card, won't this happen after i reboot because a dev has decide my need to use virtualbox is my only and true need?
And even if, why would i bloat my system memory with virtualbox drivers i don't need?
That dev do that to systemd users too: don't force them (any users init, even systemd users) to load a module when you've been asked to install a package only.


josephg:
because they decide any packages that could have an unit for systemd will install the unit even if you don't use systemd.
that's kind of dirty, but it's also dirty for systemd users to my knowledge, as i think openrc init.d files are also install even user have systemd useflag and no use for them.
I have myself INSTALL_MASK="/usr/lib/systemd /etc/systemd" (thank you for the info mv, looks like i need to extend it with /lib/systemd soon)
I don't care any dev telling me my system could be broken by that, openrc is not systemd, if my system is broken because of that mask, i will filebug against openrc to fix that ; and the same devs keep warning you about that are well aware of this "problem", so if tomorrow openrc is broken because of that mask, it mean devs are well aware of it already, and they do it even knowing it ; which would raise this "problem" far over a simple bug, but to an attack.
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 778
Location: usually offline

PostPosted: Sat Jul 29, 2017 1:52 pm    Post subject: Reply with quote

mv wrote:
The whole issue is just a simple a bug in the ebuild:
The pkg_postinst() message is plainly false, because users of current openrc are not suppossed to add anything to /etc/conf.d/modules for this ebuild.
I suggest to file a bug for this ebuild that this message be removed

i'm sorry, but i don't see gentoo/openrc standard as a bug. the message is just being explicit and informational, as expected.

mv wrote:
You have to see it from the viewpoint of developers who write a general package, not for a particular distribution or init system.

in this case, the developers (of the ebuild?) do this for a particular init. nothing general or to do with any other init.

mv wrote:
josephg wrote:
i thought the USE=systemd was for this very reason.. ie to add/remove any systemd stuff (files/locations/behaviour).

The purpose of USE flags is explicitly not to prevent installation of small files. Their purpose is limited to installation of large files (or with a side effect), severe dependencies, or when the compiled binary is affected (e.g. because it links to some library or not).

define small or large? i'm pretty sure your interpretation will widely vary with many other folks here.
and there is a side effect, because openrc is trying to behave like systemd and run stuff intended for systemd.

krinn wrote:
because they decide any packages that could have an unit for systemd will install the unit even if you don't use systemd.
that's kind of dirty, but it's also dirty for systemd users to my knowledge, as i think openrc init.d files are also install even user have systemd useflag and no use for them.

if openrc files are installed, would systemd run such code? i don't believe so..
are you suggesting openrc useflag to get rid of dirty files for systemd users?

i probably wouldn't care too much about some small systemd text files, except that openrc wants to run this. and i didn't expect it! lord only knows what else is happening on my system without my knowledge :roll:
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey


Last edited by josephg on Sun Jul 30, 2017 3:00 am; edited 2 times in total
Back to top
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1562
Location: United Kingdom

PostPosted: Sat Jul 29, 2017 1:59 pm    Post subject: Reply with quote

krinn wrote:
because they decide any packages that could have an unit for systemd will install the unit even if you don't use systemd.
that's kind of dirty, but it's also dirty for systemd users to my knowledge, as i think openrc init.d files are also install even user have systemd useflag and no use for them.

Not that I agree with that approach either, but I had assumed it has been implemented that way so that the user would be able to switch back and forth between the two systems more easily if (s)he wanted to. Is that not the case? Because, if it isn't possible to switch back and forth, I can see no good reason for systemd files to be installed in a Gentoo installation using OpenRC or for OpenRC files to be installed in a Gentoo installation using systemd. What *is* the purpose of installing systemd files if the user has USE="-systemd", and what *is* the purpose of installing OpenRC files if the user has USE="systemd"? That's not a rhetorical question, I am perplexed by the whole thing.
_________________
Clevo W230SS: amd64 OpenRC elogind nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64 OpenRC elogind xf86-video-ati. Dual boot Win 7 Pro 64-bit.
KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6855

PostPosted: Sat Jul 29, 2017 2:09 pm    Post subject: Reply with quote

Fitzcarraldo wrote:
Is that not the case? Because, if it isn't possible to switch back and forth

No idea, i know only the openrc->systemd path is handle (because openrc is default and the path to goes systemd must exist from openrc->systemd).
Even if it's doable to revert from systemd->opernc, i'm not sure if a user would do that ; you don't get back from systemd, because it's too awesome! (i couldn't refrain myself, can this be taken just like it is ; a little joke rather than derail to systemd politics thread?)

I think the key to this is: no handling of systemd or -systemd useflag in all packages just for unit or init.d files.
Yeah, for me laziness drive this choice.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sat Jul 29, 2017 3:24 pm    Post subject: Reply with quote

josephg wrote:
[i'm sorry, but i don't see that as a bug. that is the gentoo/openrc standard

No, it is not. If it is in load-modules.d it has nothing lost in conf.d/modules.
Quote:
define small or large? i'm pretty sure your interpretation will widely vary with many other folks here.

Of course. That's why this policy is questionable and often a topic of discussion. However, it is gentoo policy developers agreed upon. If you do not agree, try to change the policy but don't shoot the messenger.
Quote:
and there is a side effect, because openrc

There is the "side effect" that it works under openrc. Except that there is a wrong message printed.
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 778
Location: usually offline

PostPosted: Sat Jul 29, 2017 3:31 pm    Post subject: Reply with quote

mv wrote:
josephg wrote:
[i'm sorry, but i don't see that as a bug. that is the gentoo/openrc standard

No, it is not. If it is in load-modules.d it has nothing lost in conf.d/modules.

so you're now saying that gentoo/openrc has changed policy to automagically run stuff from systemd locations like load-modules.d even on systems without systemd, even with load-modules service disabled on all runlevels?
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey


Last edited by josephg on Sat Jul 29, 2017 6:01 pm; edited 1 time in total
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2653
Location: Illinois, USA

PostPosted: Sat Jul 29, 2017 3:44 pm    Post subject: Reply with quote

josephg wrote:
i thought the USE=systemd was for this very reason.. ie to add/remove any systemd stuff (files/locations/behaviour). why aren't gentoo devs using this for all affected packages?
A very good question, isn't it?
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sat Jul 29, 2017 4:00 pm    Post subject: Reply with quote

krinn wrote:
mv wrote:
@krinn: You have to see it from the viewpoint of developers who write a general package

No i have to see it like it need to be seen: from the point of the view of the user, or the sysadmin

Which doesn't change anything for me: If I install a package, I expect it to be installed with a sane standard configuration (if possible). Of course, there might be very few packages for which this is not possible, but these should be exceptional. If you do not want to have this luxury: I suggest to use INSTALL_MASK="/etc /var" and read the full documentation of every package you install and adapt it to your needs and for every machine individually (or using some individually configured automation of your choice). I prefer to stay away from this redundant work and find it convenient to get the configuration and change it only if I do not agree with it.
Quote:
oh my users are dumb ass and they will complains virtualbox doesn't work because they forget or are too dumb to load the modules: i will force these modules load for them then.

For me it is: Oh, my users will perhaps try whether my package is for them, without wanting to read tons of documentations before. And most likely my users do not want to wonder about strange error messages because the module needed to use my software is not loaded. Those exceptional users who want to install my software but do not intend to use it, are probably clever enough to read the standard documentation of the init system they are using to prevent the default loading of modules they do not desire.
Quote:
This is a systemd directory location

No. It is not in any .../systemd/.. directory. In fact, it is a standard location like /etc/hostname or /etc/udev. Init systems can or cannot honour these 3 (and other) locations. I prefer init systems which do, but you are free to use other init system or patch your init system to not honour these files.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sat Jul 29, 2017 4:16 pm    Post subject: Reply with quote

josephg wrote:
so you're now saying that gentoo/openrc has changed policy to automagically run stuff from systemd locations like load-modules.d

As I said (parallel to your posting): modules-load.d is not a systemd location. It is a general location with a general purpose.
And yes, openrc now supports this location. It does so by having in "modules" depend() on "want modules-load", so you have to change the latter if for some strange reason you want support for only conf.d/modules but not for all other distributions' standard location modules.load.d
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2653
Location: Illinois, USA

PostPosted: Sat Jul 29, 2017 4:36 pm    Post subject: Reply with quote

mv wrote:
... but not for all other distributions' standard location modules.load.d

But all other distributions (with minor exceptions) require systemd. So you are saying Gentoo is a systemd dstribution and OpenRC is an aberration to be shoved off to the side. Supports my thesis that Gentoo should be forked into Gentoo and Gentoo.d

EDIT: spelling


Last edited by Tony0945 on Sat Jul 29, 2017 4:52 pm; edited 1 time in total
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sat Jul 29, 2017 4:43 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Given the systemd appetite for assimilating things, the cynic in me sees this as the first step to systemd assimilating then destroying openrc.

I think you overestimate the role of openrc. It is really not important to the systemd developers whether openrc does or does not support a new standard location of files.
And even if they do: ff openrc would stay retarded and refuses to support all new standards introduced since 2010 or so, they could (rightfully) hold it against openrc.
Yes, I see a huge difficulty that meanwhile new standards in init systems practically only have a chance to appear if the systemd developers agree to support them.
But this is even more a reason to support these standards (if they are sane, of course) instead of fighting them.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sat Jul 29, 2017 4:58 pm    Post subject: Reply with quote

Tony0945 wrote:
mv wrote:
... but not for all other distributions' standard location modules.load.d

But all other distributions (with minor exceptions) require systemd.

That's how support for this standard location is implemented on most distributions. Yes. Exactly like support for /etc/hostname and /etc/udev is implemented on most distributions through systemd. So what? Do you intend to remove support for everything which on some distribution is implemented through systemd? Or support the standard only if it is supported also by a certain critical number of independent init systems? But how can you do the latter if you even complain if an init system decides to support such a new standard? The latter is the road to stagnancy.
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 778
Location: usually offline

PostPosted: Sat Jul 29, 2017 6:26 pm    Post subject: Reply with quote

mv wrote:
krinn wrote:
This is a systemd directory location

No. It is not in any .../systemd/.. directory. In fact, it is a standard location like /etc/hostname or /etc/udev.

at the risk of repeating ourselves, you stand corrected sir. this is very much a systemd location. it is documented, and i can provide you references, or you can search systemd docs yourself.

standards happen when everyone agrees! everyone won't accept it as standard just because you say so, or systemd has decided it should be the standard everyone else should follow. no others claim to set standards for everyone else.. claiming that only your decisions can be the standards everyone else should follow is taking the choice away from others.. contrary to the Gentoo Philosophy imho

mv wrote:
NeddySeagoon wrote:
Given the systemd appetite for assimilating things, the cynic in me sees this as the first step to systemd assimilating then destroying openrc.

I think you overestimate the role of openrc. It is really not important to the systemd developers whether openrc does or does not support a new standard location of files.
And even if they do: ff openrc would stay retarded and refuses to support all new standards introduced

i see a certain attitude from systemd proponents which make me very wary of encouraging them to be standard keepers. and the same goes for gnome too. remember how gnome got trashed by gnome2 which got trashed by gnome3.. betcha gnome4 will dump everything gnome3 :P i'm just waiting for systemd2

NeddySeagoon wrote:
There is no technical basis for this decision ... yet.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sun Jul 30, 2017 5:57 am    Post subject: Reply with quote

josephg wrote:
it is documented, and i can provide you references, or you can search systemd docs yourself.

Of course, it is documented in systemd, because it is supported by systemd. As is /etc/hostname and /etc/udev and many other systemd-only and not systemd-only things.
Quote:
standards happen when everyone agrees!

This never happens. By this ideal definition, there are no standards at all.
Reality is: there are formal standards and de-facto standards. Formal standards (across all groups of developers) almost do not exist in the computer world, an exception being perhaps POSIX and (already much less) FHS. And also these two react only after many years to what already has become the de-facto standard before. And moreover, several things included in these formal standards are sometimes de facto not honoured for various reasons.
Quote:
i see a certain attitude from systemd proponents which make me very wary of encouraging them to be standard keepers

I completely agree. That's why I try to distinguish between systemd stuff and things which have become a de-facto standard since the large distributions have switched to systemd as sharp as possible. Of course, systemd fanboys are interested in blurring the boundaries: Everything useful developed since then should be attributed only to them.
Unfortunately, the fact is: If there is a good candidate for a de-facto standard which needs support from the boot system, it is currently (as long as the large distributions do use systemd) necessary to include it in systemd. So in reality, systemd developers already have the possibility of a negative veto. This is very sad. But it cannot be changed by simply rejecting any new feature just "because it is implemented in systemd". This would just play in their hands: It would increase the number of de-facto standards and useful features only supported by systemd. If just enough useful features are ignored by all other init systems, it becomes impossible that large distributions will ever switch away again from systemd, and distributions not using systemd will need even more hand-work and patches. An example of this hand-work is exactly the (meanwhile wrong) pkg_postinst message from this thread: Having to tell the user to edit a config-file, because the package manager is unable to install a sane default config in a standard location, is not a good thing.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6855

PostPosted: Sun Jul 30, 2017 7:29 am    Post subject: Reply with quote

mv wrote:
Having to tell the user to edit a config-file, because the package manager is unable to install a sane default config in a standard location, is not a good thing.

THIS IS NOT A SANE DEFAULT CONFIG!!!
It is a file to force loading module on a system when the sysadmin didn't ask you do to that.

mv wrote:
If I install a package, I expect it to be installed with a sane standard configuration (if possible).

That's why we have etc-update "mechanism", you install your default config file to help user, BUT without fucking his own config ; and user thru etc-update decide on the action to take.
And this work.

mv wrote:
For me it is: Oh, my users will perhaps try whether my package is for them, without wanting to read tons of documentations before. And most likely my users do not want to wonder about strange error messages because the module needed to use my software is not loaded.

And your reaction to "oh my users want try a package" is "oh let's fuck their system"...

For ones that want a real saner setup, as it will really fix the issue
Code:
INSTALL_MASK="/usr/lib/modules-load.d"
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sun Jul 30, 2017 9:23 am    Post subject: Reply with quote

krinn wrote:
THIS IS NOT A SANE DEFAULT CONFIG!!!

It makes no sense to repeat the arguments. Most people will consider it sane to have the system configured such that they can run the programs they installed. Some people don't.
Quote:
That's why we have etc-update "mechanism"

Yes, every distribution has its own horrible hacks to deal with the /etc hell. None of these hacks is good, and all are horrible to store such that the system and local changes can be reproduced reliably.
The best solution to the issue has come up with udev and is now fortunately also standard in many tools, meanwhile:
The default configs are stored in the main tree (so they can easily be used and included), and only modifications to them are stored in /etc. "Modifications" can include complete removal by means of linking to /dev/null.
This happens to be the case with modprobe.d, moidules-load.d, udev, and hopefully soon for much more. This mechanism is obvious, local changes to the defaults are clearly visible, and it is trivial to reset things to the default configuration. Moreover, it is trivial to change distribution-wide default.
Quote:
you install your default config file to help user

Do you? Which default config file do you install for a kernel module?
I went through this nightmare before: I had first written code in the ebuild which attempts to add the module to /etc/conf.d/modules. This is necessarily is an ugly hack, since it is of course not possible to make a reliably working suggestion how to modify the possibly complex shell code in /etc/conf.d/modules.
But it was far worse: After each openrc bump/re-emerge the defaults wanted to reset, and then again after each emerge of my package, etc-update reported changes. The reason is simply that there is a (config) file collision between two packages. Such things simply must always be avoided.
End of the story is that the etc-mechanism simply is too hackish and cannot be sanely used for files which need to be extended by several packages.

My decision in the end was to hack into /etc/conf.d/modules a mechanism to add support for /etc/load-modules.d. How glad I was, that this mechanism was then finally implemented in openrc, even in the sane way mentioned above.
Quote:
For ones that want a real saner setup, as it will really fix the issue
Code:
INSTALL_MASK="/usr/lib/modules-load.d"

Yep: Everybody who wants full manual control - in particular, to read the full documentation of every package he installs and enjoys wondering why things are not working out-of-the-box if he has missed a small remark somewhere - should do this. And do not forget to also add /etc to INSTALL_MASK so that nothing can ever mess up your configs.

Edit: typos and:

I agree that it might be a good idea to add /lib/modules-load.d, /lib/modprobe.d, and /lib/tmpfiles.d (and /usr/lib/...) to CONFIG_PROTECT. Unfortunately, the etc-update mechanism does not inform you about new files there (when you install new packages). Perhaps somebody wants to send a feature request for portage to support such a thing.


Last edited by mv on Sun Jul 30, 2017 9:38 am; edited 1 time in total
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 778
Location: usually offline

PostPosted: Sun Jul 30, 2017 9:35 am    Post subject: Reply with quote

mv wrote:
The default configs are stored in the main tree (so they can easily be used and included), and only modifications to them are stored in /etc.

mv wrote:
This mechanism is obvious, local changes to the defaults are clearly visible, and it is trivial to reset things to the default configuration. Moreover, it is trivial to change distribution-wide default.

i like this bit! so a system with no modifications should have an almost empty /etc?
and where do you draw the line? if you do everything systemd does, you might as well use systemd!
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sun Jul 30, 2017 10:05 am    Post subject: Reply with quote

josephg wrote:
i like this bit! so a system with no modifications should have an almost empty /etc?

If all tools would follow this format, then yes. I have no statistic about their number.
Quote:
and where do you draw the line?

I cannot tell people what to do. Every upstream decides what he considers sane, and every ebuild author decides whether he follows upstream or patches things out.
My "personal" line (in my projects and my setups) is: The modprobe.d, load-modules.d, tmpfiles.d, and udev directories are great (together with the above mechanism), and these are the only things which I consider to be independent from systemd (in fact, all 4 of them also do have at least 1 independent implementation I am aware of). I do not like most of the other systemd concepts; especially, I do not consider the whole dbus mechanism secure enough to run on my system. I have installed and configured systemd for possible booting/usage in emergency cases, though.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41565
Location: 56N 3W

PostPosted: Sun Jul 30, 2017 12:05 pm    Post subject: Reply with quote

josephg,

Then we would need an openrc USE, so that small openrc files were not installed on systemd systems.
We are talking about a number of small files so the HDD space is not important.
There was a debate on the -dev ML. The consensus was that by not installing these files it made the transitions between init systems more difficult, since to get them, you ned to reinstall the packages that provided them.

Providing you allow both sets of small files to install, its possible to dual boot openrc and systemd in the same install by changing the init= in the boot loader configuration.

mv was correct that
Code:
INSTALL_MASK="/usr/lib/modules-load.d"
is more a political statement now than it was a few years ago when it was set.
I'm more aware signs of encroachment by systemd that I was when I created that entry. If I knew then what I know now, I probably wouldn't have bothered.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 778
Location: usually offline

PostPosted: Sun Jul 30, 2017 12:57 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Then we would need an openrc USE, so that small openrc files were not installed on systemd systems.

and why not.. isn't that the purpose of useflags? particularly when those (small or not) files affect system behaviour.

NeddySeagoon wrote:
There was a debate on the -dev ML. The consensus was that by not installing these files it made the transitions between init systems more difficult, since to get them, you ned to reinstall the packages that provided them.

josephg wrote:
if openrc files are installed, would systemd run such code? i don't believe so..

NeddySeagoon wrote:
Providing you allow both sets of small files to install, its possible to dual boot openrc and systemd in the same install by changing the init= in the boot loader configuration.

who in their right mind would install both openrc and systemd to switch back and forth in any type of production (server/desktop/laptop/mobile/etc) environment? the stable target should always be a production environment. i can see this need for testers perhaps, but not for general users. devs can do whatever with -9999 or even perhaps ~arch.

Fitzcarraldo wrote:
krinn wrote:
because they decide any packages that could have an unit for systemd will install the unit even if you don't use systemd.
that's kind of dirty, but it's also dirty for systemd users to my knowledge, as i think openrc init.d files are also install even user have systemd useflag and no use for them.

Not that I agree with that approach either, but I had assumed it has been implemented that way so that the user would be able to switch back and forth between the two systems more easily if (s)he wanted to. Is that not the case? Because, if it isn't possible to switch back and forth, I can see no good reason for systemd files to be installed in a Gentoo installation using OpenRC or for OpenRC files to be installed in a Gentoo installation using systemd. What *is* the purpose of installing systemd files if the user has USE="-systemd", and what *is* the purpose of installing OpenRC files if the user has USE="systemd"? That's not a rhetorical question, I am perplexed by the whole thing.


josephg wrote:
mv wrote:
This mechanism is obvious, local changes to the defaults are clearly visible, and it is trivial to reset things to the default configuration. Moreover, it is trivial to change distribution-wide default.

i like this bit! so a system with no modifications should have an almost empty /etc?
and where do you draw the line?

mv wrote:
My "personal" line (in my projects and my setups) is: The modprobe.d, load-modules.d, tmpfiles.d, and udev directories are great (together with the above mechanism)

and why stop there.. you can't say this is a better way only for these four directories? why not go further.. let's streamline the whole process and have as gentoo policy to install config files only in /lib, and leave /etc for sysadmin configs only!

but please do this overtly, and not covertly sneaking in things contrary to existing policy or docs. discussion helps. it is possible to arrive at consensus, unless some think that all others are haters/greybeards/etc. if not, there's always forks to live and let live!

Tony0945 wrote:
So you are saying Gentoo is a systemd dstribution and OpenRC is an aberration to be shoved off to the side. Supports my thesis that Gentoo should be forked into Gentoo and Gentoo.d


Last edited by josephg on Mon Aug 07, 2017 7:58 am; edited 1 time in total
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sun Jul 30, 2017 2:18 pm    Post subject: Reply with quote

josephg wrote:
NeddySeagoon wrote:
Then we would need an openrc USE, so that small openrc files were not installed on systemd systems.

and why not.. isn't that the purpose of useflags?

As already mentioned: No. Since quite a while gentoo has set up the policy that USE must not be introduced to force/omit the installation of small files. Typical examples mentioned in this connection were zsh-completion and bash-completion files which are now usually installed unconditionally (although a few packages still have these USE-flags; maybe these are bugs or the flags serve a different purpose here.)
Since this policy was cited so often (in many bugs and on devlist), I was quite sure it is on a prominent place in the developer's hand book. Howver, the best I could find in the moment is this:
https://devmanual.gentoo.org/general-concepts/use-flags/ wrote:
The usage of a USE flag should not control runtime dependencies when the package does not link to it.
This is not explicitly mentioning small files, but at least implicitly said files would require a dependency. Maybe somebody can help out with a better referemce?
Quote:
let's streamline the whole process and have as gentoo policy to install config files only in /lib, and leave /etc for sysadmin configs only!

This is not something which a small distribution like gentoo can decide: For Gentoo, this must come from the upstream packages.
In theory, a distribution could patch every single package which uses a config-file in /etc, but in practice this would exceed Gentoo's available manpower. Maybe Debian or Redhat have such a policy - I don't know. They would both have the manpower, and moreover, for them it might mean more than just convenience, since starting with in empty /etc is what they might want to achieve for virtual machines and containers.
Quote:
discussion helps. it is possible to arrive at consensus

Not really. Even in POSIX many people do not agree with the decisions being made. And in POSIX things are relatively simple since a consensus can be "forced" by voting. There is no institution which can describe free software how to behave. This can be viewed as good or bad. Concerning any standardization, it is a severe obstacle. On the other hand, "official" standardization can also be a severe ball and chain as can be seen with PMS and how it prevents new useful features being added (new EAPI's practically do not appear due to bikeshedding etc.)

Edit: Added my finiding about the USE-flag policy.
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 778
Location: usually offline

PostPosted: Sun Jul 30, 2017 2:52 pm    Post subject: Reply with quote

mv wrote:
Quote:
let's streamline the whole process and have as gentoo policy to install config files only in /lib, and leave /etc for sysadmin configs only!

This is not something which a small distribution like gentoo can decide: For Gentoo, this must come from the upstream packages.

i'm talking about gentoo packages.
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sun Jul 30, 2017 4:24 pm    Post subject: Reply with quote

josephg wrote:
mv wrote:
Quote:
let's streamline the whole process and have as gentoo policy to install config files only in /lib, and leave /etc for sysadmin configs only!

This is not something which a small distribution like gentoo can decide: For Gentoo, this must come from the upstream packages.

i'm talking about gentoo packages.

That's not a large number of packages. Essentially, I think openrc is the only gentoo project which uses default configuration files (besides eudev which already uses said mechanism). Well, there is also /etc/dispatch-conf.conf and /etc/etc-update, but I think that's it. Portage itself already uses kind of such a mechanism by storing the defaults in /usr/share/portage/config and allowing override.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Jul 30, 2017 6:34 pm    Post subject: Reply with quote

mv wrote:
@krinn: You have to see it from the viewpoint of developers who write a general package
krinn wrote:
No i have to see it like it need to be seen: from the point of the view of the user, or the sysadmin
mv wrote:
Which doesn't change anything for me: If I install a package, I expect it to be installed with a sane standard configuration (if possible). Of course, there might be very few packages for which this is not possible, but these should be exceptional. If you do not want to have this luxury: I suggest to use INSTALL_MASK="/etc /var" and read the full documentation of every package you install and adapt it to your needs and for every machine individually (or using some individually configured automation of your choice). I prefer to stay away from this redundant work and find it convenient to get the configuration and change it only if I do not agree with it.
This is a completely specious argument that has nothing to do with automagically enabling modules just because they are installed (with some package.)
Quote:
Oh, my users will perhaps try whether my package is for them, without wanting to read tons of documentations before. And most likely my users do not want to wonder about strange error messages because the module needed to use my software is not loaded. Those exceptional users who want to install my software but do not intend to use it, are probably clever enough to read the standard documentation of the init system they are using to prevent the default loading of modules they do not desire.
Funny, above I could swear you were talking about distributions and installers.
These kinds of choices are down to the distribution; Gentoo has never automagically enabled anything just because it is installed.
The closest parallel is with daemons; just because they're installed, does not mean the admin is ready to deal with them being started automatically, nor even wants that.

If a bindist wants to, that's their choice, and sod-all to do with what is best for Gentoo users.
And yes, what you're discussing here is again from the point of view of an upstream developer; and sorry, no you don't always know best: that's why we have distros.

Gentoo is not an idiot-box distribution; if an admin wants to set up autoload for their users, they can do it themselves.
The alternative breaks the principle of least-surprise, for no good reason, especially so given the context.
Quote:
it is a standard location like /etc/hostname or /etc/udev. Init systems can or cannot honour these 3 (and other) locations. I prefer init systems which do, but you are free to use other init system or patch your init system to not honour these files.
More specious nonsense.
Please, stop disparaging people who disagree with you, using arguments you have made up and assigned to them.

Just because someone runs around shouting that something is a "standard", and we should all get used to it, does not make it so.
Though much is usually inferred from the fact that they need to promote it so heavily, instead of letting it speak for itself.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum