Abstract Most ebuilds which depend on baselayout require a specific version, which causes major headaches with virtual/baselayout. Motivation The current use of virtual/baselayout leads to broken dependencies in vservers like in bug 105616 or the impossibility to build vserver stage1 with catalyst due to hackish use of sys-apps/baselayout(-vserver) in the profiles. See GLEP37 for details. Implementation 1) New-style virtual 01-virtual.diff 2) Required profile changes 02-profiles-base.diff 02-profiles-alpha.diff 02-profiles-amd64.diff 02-profiles-base.diff 02-profiles-hardened.diff 02-profiles-hppa.diff 02-profiles-ia64.diff 02-profiles-ppc.diff 02-profiles-selinux.diff 02-profiles-x86.diff 3) ebuilds which have sys-apps/baselayout hardcoded 03-app-emulation-vmware-workstation.diff 03-app-laptop-pbbuttonsd.diff 03-app-misc-lcdproc.diff 03-media-gfx-splashutils.diff 03-net-fs-openafs-legacy.diff 03-net-misc-bridge-utils.diff 03-net-wireless-linux-wlan-ng.diff 03-net-wireless-wireless-tools.diff 03-sci-biology-foldingathome.diff 03-sci-mathematics-gimps.diff 03-sys-apps-policycoreutils.diff 03-sys-apps-rsbac-admin.diff 03-sys-fs-evms.diff 03-sys-fs-udev.diff 03-sys-power-apcupsd.diff All patches can be found at http://dev.gentoo.org/~hollow/baselayout/ It's probably best to commit (at least the virtual + profiles) at one time, just wanted to hear some opinions before.
Re: x86 profiles: Do not make the proposed changes. While it won't necessarily *hurt* anything, the profiles you have mentioned are specific to specific release versions and *do* use and require sys-apps/baselayout. We can ensure that *future* profiles are using the virtual, but I would prefer we not touch the current profiles. Any profiles which inherit these profiles can negate any part of the profile, so I do not see the point. I didn't look over the other architecture patches, but I would bet that the same applies there, too. Re: vmware-workstation: It does require >=sys-apps/baselayout-1.11.14 to function properly. If every single package that fulfills virtual/baselayout is 100% compatible in how it runs init scripts, then the change can be made, but the dependency is there for a reason, so changing it arbitrarily is not a good idea.
(In reply to comment #1) > Re: x86 profiles: Do not make the proposed changes. While it won't necessarily > *hurt* anything, the profiles you have mentioned are specific to specific > release versions and *do* use and require sys-apps/baselayout. We can ensure > that *future* profiles are using the virtual, but I would prefer we not touch > the current profiles. ok, just wanted to make it "clean" but you're right that this only applies for future profiles > Any profiles which inherit these profiles can negate any > part of the profile, so I do not see the point. Last time i was not able to build stage1/2 with catalyst because it simply did not get deps like this right: ->=sys-apps/baselayout-1.11.12-r4 -*sys-apps/baselayout *sys-apps/baselayout-vserver > I didn't look over the other > architecture patches, but I would bet that the same applies there, too. > > Re: vmware-workstation: It does require >=sys-apps/baselayout-1.11.14 to > function properly. If every single package that fulfills virtual/baselayout is > 100% compatible in how it runs init scripts, then the change can be made, but > the dependency is there for a reason, so changing it arbitrarily is not a good > idea. > well, i'd prefer to see sys-apps/baselayout in vservers, but the baselayout guys are not that cooperative otoh, we could just put those few ebuild to p.mask which depend on sys-apps/baselayout and better do so in the future (except gimps and foldingathome, none of these is probably ever used in vservers, though it wouldn't be a problem technically) the main problem here seems with udev, which depends on sys-apps/baselayout, and some depend on udev... it's a crazy mess...
(In reply to comment #2) > Last time i was not able to build stage1/2 with catalyst because it simply did > not get deps like this right: > > ->=sys-apps/baselayout-1.11.12-r4 > -*sys-apps/baselayout > *sys-apps/baselayout-vserver Stage1 doesn't use packages, but packages.build instead. The packages file determines the "system" target, while packages.build determines what packages to shove into a stage1 tarball.
after chris pointed me to p.build, and some other minor tweaks and moves, it now works without a new-style virtual... so, leaving this as invalid sorry for the spam guys!
