This comes from bug 479986 and bug 468500. For better experience of any systemd user (not depending on him running gnome/kde/...) we would need to set some USE flags defaults, masking... Would also allow us (gnome team) to have a desktop/systemd/gnome profile inheriting them For now I see the following issues: - Setting of "systemd" USE flag -> as mgorny commented, this *cannot* be done due circular dep problems when people have sys-fs/udev installed. Will need to wait as I don't think we have a way to enable it *only* when sys-apps/systemd is already installed, is there any? - "consolekit" USE flag -> should probably be masked in that profile to prevent problems, but will wait for bug 478258 feedback to know if it can be masked globally or per package - "static-libs" issue -> we need to mask it in virtual and co to prevent dependency blocking issues And probably there are more I am forgetting now (regarding lvm, genkernel...)
OK, Samuli was true -> we would need to mask "consolekit" USE flag globally in this profile
Are you capable of building our own stages?
I don't know how are they even built :/ if someone could teach me. Anyway we should offer that stages "officially" (I mean, they should be downloadable from the same source or, at least, have a reference to their location in docs). But probably the simplest solution would be to build stages with sys-apps/systemd as udev provider (even having rest of packages included on them built with "-systemd" USE). Has anyone contacted release team about this? People wanting to revert to sys-fs/udev should simply run "emerge -1 udev" and nothing should break
Could eselect profile module be changed to die (and show a warning) when people tries to switch to that profile *before* installing sys-apps/systemd?
I also doubt about where this kind of profile should be placed :/ Should it be under "targets", "features"? I guess, systemd isn't only for desktops and, then, should be "over" desktop profile
*** Bug 479986 has been marked as a duplicate of this bug. ***
*** Bug 480172 has been marked as a duplicate of this bug. ***
In my opinion profile must be added to root since it could be useful for people who will install gentoo with systemd in general, I'm sure that there are some people who want. And then other profiles build on it systemd/desktop systemd/desktop/gnome.
I agree with that, but still need to start trying to do it :S ;)
Looks like we would need to have profiles like: default/linux/amd64/13.0/ for every arch supporting systemd :/ Looks a bit complicated but I don't see other better place where to put it. Any ideas?
I'm agreed with: default/linux/amd64/13.0/systemd/ and don't see another way too. Maybe it's also possible to use something alike: systemd/linux/amd64/13.0/ but I personally like first variant more because it will be available to make hardened with systemd for example.
Created attachment 359664 [details] profile.tar.xz This is the idea: - It adds a profile/default/linux/amd64/13.0/desktop/gnome/systemd/ that simply inherits ".." (to get desktop/gnome profile settings) and systemd target path to get additional settings - It adds profile/targets/systemd for putting our settings
(In reply to Pacho Ramos from comment #12) > Created attachment 359664 [details] > profile.tar.xz > > This is the idea: > - It adds a profile/default/linux/amd64/13.0/desktop/gnome/systemd/ that > simply inherits ".." (to get desktop/gnome profile settings) and systemd > target path to get additional settings > - It adds profile/targets/systemd for putting our settings I think lvm2 would use masking USE=static as well. Other than that, I don't have any immediate suggestions.
(In reply to Michał Górny from comment #13) > (In reply to Pacho Ramos from comment #12) > > Created attachment 359664 [details] > > profile.tar.xz > > > > This is the idea: > > - It adds a profile/default/linux/amd64/13.0/desktop/gnome/systemd/ that > > simply inherits ".." (to get desktop/gnome profile settings) and systemd > > target path to get additional settings > > - It adds profile/targets/systemd for putting our settings > > I think lvm2 would use masking USE=static as well. Other than that, I don't > have any immediate suggestions. OK, I guess I need to mail to gentoo-dev ML to get this "approved", no? (I have never added a new profile :S)
(not strictly a blocker since it's not a regression over current situation -> people will need to switch profile when they have dbus installed)
+ 09 Oct 2013; Pacho Ramos <pacho@gentoo.org> + +default/linux/amd64/13.0/desktop/gnome/systemd/parent, + +default/linux/arm/13.0/desktop/gnome/systemd/parent, + +default/linux/powerpc/ppc32/13.0/desktop/gnome/systemd/parent, + +default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome/systemd/parent + , + +default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/gnome/systemd/parent + , +default/linux/powerpc/ppc64/13.0/desktop/gnome/systemd/parent, + +default/linux/x86/13.0/desktop/gnome/systemd/parent, profiles.desc, + +targets/systemd/make.defaults, +targets/systemd/package.mask, + +targets/systemd/package.use.mask, +targets/systemd/use.mask: + Add systemd subprofiles (#481920 and + http://gentoo.2317880.n4.nabble.com/Addition-of-systemd-subprofiles-td270299. + html ) +
(In reply to Michał Górny from comment #13) [...] > I think lvm2 would use masking USE=static as well. Other than that, I don't > have any immediate suggestions. Also done, I think all is covered regarding static* stuff
Please do this for kde too, as kde-4.11 has propper logind support.
(In reply to Johannes Huber from comment #18) > Please do this for kde too, as kde-4.11 has propper logind support. Sure, it's only a matter of adding the relevant "parents" for the arches you are supporting (I guess ppc*, arm, amd64 and x86 too...) Will look at it soon (but you can also do that if you want it a bit faster;)), I did only gnome subprofiles as they were the profiles I am using daily (I only use gnome)
(In reply to Pacho Ramos from comment #19) > Sure, it's only a matter of adding the relevant "parents" for the arches you > are supporting (I guess ppc*, arm, amd64 and x86 too...) You are right! > Will look at it soon (but you can also do that if you want it a bit > faster;)), I did only gnome subprofiles as they were the profiles I am using > daily (I only use gnome) No need to rush. Thanks in advance.
+ 19 Oct 2013; Pacho Ramos <pacho@gentoo.org> + +default/linux/amd64/13.0/desktop/kde/systemd/parent, + +default/linux/arm/13.0/desktop/kde/systemd/parent, + +default/linux/powerpc/ppc32/13.0/desktop/kde/systemd/parent, + +default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd/parent, + +default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde/systemd/parent, + +default/linux/powerpc/ppc64/13.0/desktop/kde/systemd/parent, + +default/linux/x86/13.0/desktop/kde/systemd/parent, profiles.desc: + Add kde/systemd variants too (#481920#c20) + For the future, please open new bugs to prevent the reopening from trigger a lot of mails from bugs depending on this Thanks
Please change the STATUS back to IN_PROGRESS I know this has been ended, however, I would like to know if there is a chance of a profile for default/linux/amd64/13.0/desktop/systemd in the works. I have about 15 desktops installed from Afterstep to Xterm as I use my system to show people just what Linux is capable of and how configurable it can be for any taste. I personally switch between E17 & Mate as the mood takes me. I don't know what effect having the profile on default/linux/amd64/13.0/desktop/gnome/systemd or default/linux/amd64/13.0/desktop/kde/systemd has to installing packages for all the desktops I have installed, so currently I am using the generic default/linux/amd64/13.0/desktop profile.
I would open a separate bug report and involve there systemd team freedesktop mail alias. I have no problems on adding it, but I am unsure if other could have (originally, I added gnome one as that is the one I was going to use and we needed it, later kde team also agreed on having one... but I am not sure if xfce/lxde maintainers will have any problem with that (they should be working ok with a system running systemd and not consolekit... but I am not sure)
