Per this IRC log, looks like upstream prefers to set this configure option for cases like Gentoo, where we don't have yet the /usr merge: --- Log opened Mon Mar 11 21:36:03 2013 21:36 < WilliamH> poettering: Hey, if you are around, I have a question. 21:37 < WilliamH> poettering: on gentoo, our systemd maintainer is installing everything in /usr, and we do not have / and /usr merged. From autogen.sh, I don't think that's a good idea, 21:37 < WilliamH> poettering: correct? 21:42 < mbiebl> WilliamH: do you have mount-usr-in-initramfs support? 21:45 < poettering> WilliamH: either you split /usr, or you don't 21:46 < poettering> WilliamH: if you install everything to /usr, but don't merge the dirs 21:46 < poettering> WilliamH: then you get the worst of both 21:46 < poettering> WilliamH: because now your binaries are in different paths than on any other distro 21:46 < poettering> WilliamH: which is totally the opposite of what the usr merge is supposed to achieve: that either path works 21:47 < poettering> so, yeah, it's a *really* bad idea to install everything to /usr without doing the full merge 21:47 < poettering> it's the worst possible choice 21:47 < poettering> any honestly, not merging /usr is hardly better, but i figure gentoo is into this kind of retro shit, and actually is proud of it... 22:01 < seblu> I've some message from logger generated from acpid scripts which escape the units of acpid.service via journalctl -u acpid 22:02 < seblu> how that's is possible, the journal should not ensure that message behind a service (cgroup) going into the right _SYSTEMD_UNIT? 22:08 < WilliamH> poettering: heh, some of us in gentoo are actually working on changing that. 22:09 < WilliamH> poettering: It is just taking some time and a lot of debate. 22:09 < WilliamH> poettering: I did a lot of reading on the /usr merge and personally it makes a lot of sense to me. 22:11 < WilliamH> poettering: I'll admit it didn't at first, but I thought it over and it really does make sense to me. --- Log closed Mon Mar 11 22:14:00 2013 As a side note, would be nice to clarify the /usr merge problem, as I agree current mixed situation is really ugly as there are a lot of apps relying on files in /usr. But, until then, as I can read from Lennart's comments, looks like upstream don't like to have systemd files forced into /usr in this case Thanks a lot Reproducible: Always
CCing udev team too as this problem was raised to me when I was trying to clarify what moves could be done to be able to make udev provided by systemd ebuild replace current udev ebuilds (that are a bit hard to maintain and extend) Thanks!
This again? If something is broken, please be specific.
(In reply to Mike Gilbert from comment #2) > This again? If something is broken, please be specific. Sure. Emerge of sys-apps/systemd forces uninstall of sys-fs/udev. Then libudev.so.1 will move from / to /usr and break systems with USE="-static" cryptsetup and/or lvm2
(In reply to Samuli Suominen from comment #3) > (In reply to Mike Gilbert from comment #2) > > This again? If something is broken, please be specific. > > Sure. > > Emerge of sys-apps/systemd forces uninstall of sys-fs/udev. Then > libudev.so.1 will move from / to /usr and break systems with USE="-static" > cryptsetup and/or lvm2 Also, if you pass --with-rootprefix= udev gets installed in /, which is where it needs to be, without manually moving it around like is being done in the current system ebuild.
(In reply to Samuli Suominen from comment #3) > (In reply to Mike Gilbert from comment #2) > > This again? If something is broken, please be specific. > > Sure. > > Emerge of sys-apps/systemd forces uninstall of sys-fs/udev. Then > libudev.so.1 will move from / to /usr and break systems with USE="-static" > cryptsetup and/or lvm2 Thank you for your insight, that was really helpful and useful.
Via IRC, mgorny explained me that: (07:03:32) mgorny: except for our users having another big move of unit files for no benefit (07:03:46) mgorny: and pretending that all things actually works without /usr (07:20:29) mgorny: plus init= line invalidity I agree that moving unit files again would be a pain, not sure if maybe a symlink could help (since people running systemd will need to have /usr mounted anyway, no?) Regarding init= line... well, it can be changed :) About problem reported by ssuominen, I guess it can be solved re-emerging affected packages with revdep-rebuild/emerge @preserved-rebuild, no? If systemd team prefers to keep things as-is, maybe would be better to try to push a bit /usr merge... but I don't remember where was it blocked finally (probably some "political" issues instead of "technical" ones :S)
@pacho: For your benefit, I am going to respond here to mgorny's concerns. I have told him all of this, so I don't expect him to respond. This is just here so you know what I have told him. (In reply to Pacho Ramos from comment #6) > Via IRC, mgorny explained me that: > (07:03:32) mgorny: except for our users having another big move of unit > files for no benefit The benefit would be that the units would be in a location which would not change if we do the /usr merge, and which is compatible with non-usr-merged setups. /lib/system will be valid if we do the /usr merge, and it is valid if we do not do it. Right now, /lib/system is not a valid location, and this is the canonical location for system units as defined by upstream. > (07:03:46) mgorny: and pretending that all things actually works without /usr No, there would be no pretence here. Systemd upstream has a specific way to support this, using an initramfs. > (07:20:29) mgorny: plus init= line invalidity > > I agree that moving unit files again would be a pain, not sure if maybe a > symlink could help (since people running systemd will need to have /usr > mounted anyway, no?) We went through the same thing with moving /usr/lib/udev to /lib/udev when I fixed udev, and it wasn't a big deal; it would just be a minor eclass tweak and telling users to emerge all packages with things in /usr/lib/system. Once that is done, things would just migrate over to the right location. The one part of this I haven't worked out is that they may have to fix symlinks in /etc/system, but maybe we could do that programmatically some how after they re-emerge everything. > Regarding init= line... well, it can be changed :) Exactly. > About problem reported by ssuominen, I guess it can be solved re-emerging > affected packages with revdep-rebuild/emerge @preserved-rebuild, no? Maybe, I would have to think about this. > If systemd team prefers to keep things as-is, maybe would be better to try > to push a bit /usr merge... but I don't remember where was it blocked > finally (probably some "political" issues instead of "technical" ones :S) Unfortunately, I don't see the /usr merge happening soon. It appears that the faster solution is going to be for the udev team to commit our own flavor of system to the tree. Also, we will make sure to add the logind use flag which the gnome team, myself, and lxnay have requested.
(In reply to William Hubbs from comment #7) > The benefit would be that the units would be in a location which would not > change if we do the /usr merge, and which is compatible with non-usr-merged > setups. /lib/system will be valid if we do the /usr merge, and it is valid > if we do not do it. Right now, /lib/system is not a valid location, and this > is the canonical location for system units as defined by upstream. Units should be installed to the path specified by systemd.pc. This works fine as-is. My stance is that there is no strong argument for moving things around at this time. This "canonical" upstream location argument is not reason-enough.
If this patch was applied, bugs like #478538 would not be issues any longer.
The patch I am referring to above is the patch on bug #478538. I took out the part that adds all of the optional use flags. Would you please consider applying that patch to system?
Bugs are to be fixed and not worked around. And I'd appreciate if you stopped playing with bugs. You're not the one who they're assigned to.
