Releng is gearing up to so stage{1,2,3}-{amd64,i686}-systemd stages. Starting from a current stage3-amd64 you can obtain a stage3-amd64-systemd tarball, but you cannot use that tarball as a seed since it leads to the following circular dependency: Total: 43 packages (42 new, 1 reinstall), Size of downloads: 0 KiB * Error: circular dependencies: (sys-apps/util-linux-2.26.2:0/0::gentoo, ebuild scheduled for merge) depends on (sys-apps/systemd-226-r2:0/2::gentoo, ebuild scheduled for merge) (buildtime) (sys-apps/util-linux-2.26.2:0/0::gentoo, ebuild scheduled for merge) (buildtime_slot_op) This is easily fixed with RDEPEND=" ... !build? ( systemd? ( sys-apps/systemd ) ) ..."
The econf logic would need to be adjusted to not pass --with-systemd when USE=build. It would be best to disable the systemd flag for the first stage. Is that possible?
(In reply to Mike Gilbert from comment #1) > The econf logic would need to be adjusted to not pass --with-systemd when > USE=build. > > It would be best to disable the systemd flag for the first stage. Is that > possible? It is possible to use USE=build to configure --without-systemd but I don't think we need to do that. I didn't turn anything off because systemd's libraries are there in the stage3. Its just a means of circumventing the circular dependency. When building stage1, we can assume @system stuff is all present and not have to worry about strictly enforcing dependencies. That's precisely what USE=build is for and why we have the warning in use.desc: build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1]
(In reply to Anthony Basile from comment #2) being in the stage3 doesn't help. the stage3 is used merely as a build env to build the stage1, and the stage1 one all by itself must be free of loops. util-linux leveraging USE=build to elide systemd seems fine.
(In reply to SpanKY from comment #3) > (In reply to Anthony Basile from comment #2) > > being in the stage3 doesn't help. the stage3 is used merely as a build env > to build the stage1, and the stage1 one all by itself must be free of loops. If foo links against libbar and you emerge foo with ROOT=/tmp/stage1root, don't you need libbar in the stage3 env? > > util-linux leveraging USE=build to elide systemd seems fine. Can I go ahead commit this to 2.26.2 (current stable) and above? The above is clearly safe, but I don't see what could go wrong including the stable.
+1 from me, and committed, commit 206d99c.
(In reply to Anthony Basile from comment #4) the error you showed was from emerge's depgraph checking. but ignoring that, if we link against libs in / which aren't in $ROOT, then stage2 is going to fail too.
(In reply to SpanKY from comment #6) util-linux only links a few binaries against libsystemd, so it might not break anything in stage2. It's still kind of "dirty" though. % grep libsystemd /var/db/pkg/sys-apps/util-linux-2.27.1/NEEDED.ELF.2 X86_64;/usr/sbin/uuidd;;;libuuid.so.1,libsystemd.so.0,libc.so.6;x86_64 X86_64;/usr/bin/logger;;;libsystemd.so.0,libc.so.6;x86_64 X86_64;/usr/bin/lslogins;;;libsmartcols.so.1,libsystemd.so.0,libc.so.6;x86_64
I'm still building stages so I won't have feedback until tomorrow, but I got through the dependency calcs in the stage3 so I suspect the build flag on util-linux has resolved this. I was thinking the same thing in terms of just accepting the broken linking, though I'm not 100% sure it wouldn't cause some kind of problem. The reality is that those binaries are not needed at all until you actually want to use the resulting stage3. I have a systemd-stage3 seed which is useful for building stage1s (if you try to build a systemd stage1 from a default stage3 you get some errors that seem to be udev related). It is very easy to build a systemd stage3 by pointing the seed for it at a default stage3 - there is no circular dep issue from default stage3 to systemd stage3 (and that is basically the handbook install anyway). Once I confirm everything is working I'll upload specs/seeds/etc somewhere. Though, anybody with a faster build system and a bit more spare time might beat me to it.
(In reply to Mike Gilbert from comment #7) > (In reply to SpanKY from comment #6) > > util-linux only links a few binaries against libsystemd, so it might not > break anything in stage2. It's still kind of "dirty" though. > > % grep libsystemd /var/db/pkg/sys-apps/util-linux-2.27.1/NEEDED.ELF.2 > X86_64;/usr/sbin/uuidd;;;libuuid.so.1,libsystemd.so.0,libc.so.6;x86_64 > X86_64;/usr/bin/logger;;;libsystemd.so.0,libc.so.6;x86_64 > X86_64;/usr/bin/lslogins;;;libsmartcols.so.1,libsystemd.so.0,libc.so.6;x86_64 Which binaries should I be looking at. I'd like to have this a clean process. Remember, we're just trying to break the circular dep, that doesn't mean we can' still get systemd into stage2 to satisfy those binaries.
(In reply to Anthony Basile from comment #9) > > Which binaries should I be looking at. I'd like to have this a clean > process. Remember, we're just trying to break the circular dep, that > doesn't mean we can' still get systemd into stage2 to satisfy those binaries. That was supposed to read "... that doesn't mean we can't still ..."
I think the systemd support for util-linux was only for adding "extra" and nice features to be used with systemd (I remember "logger" took advantage of that for example) But util-linux will still "work" without USE systemd and, hence, you shouldn't hit any breakage due to this temporally disabled systemd support
(In reply to Anthony Basile from comment #9) > (In reply to Mike Gilbert from comment #7) > > (In reply to SpanKY from comment #6) > > > > util-linux only links a few binaries against libsystemd, so it might not > > break anything in stage2. It's still kind of "dirty" though. > > > > % grep libsystemd /var/db/pkg/sys-apps/util-linux-2.27.1/NEEDED.ELF.2 > > X86_64;/usr/sbin/uuidd;;;libuuid.so.1,libsystemd.so.0,libc.so.6;x86_64 > > X86_64;/usr/bin/logger;;;libsystemd.so.0,libc.so.6;x86_64 > > X86_64;/usr/bin/lslogins;;;libsmartcols.so.1,libsystemd.so.0,libc.so.6;x86_64 > > Which binaries should I be looking at. I'd like to have this a clean > process. Remember, we're just trying to break the circular dep, that > doesn't mean we can' still get systemd into stage2 to satisfy those binaries. I have no idea what I was smoking when I wrote that. Anyhow, I've done a bit of tweaking to profiles/target/systemd and now I'm getting good stage1/2/3's without any linking breakage. Everyhing appears consistent, but please test the stage3 that i just added to the mirrors at experimental/amd64/systemd.
