Re: [gentoo-dev] Questions about SystemD and OpenRC
On Tue, Aug 14, 2012 at 2:12 PM, Canek Peláez Valdés can...@gmail.com wrote: You can get as much vertical integration with Gentoo as with any other distro. The problem (and I think this is the point Greg is trying to make) is that it will be harder (not impossible, just harder) if most of Gentoo developers really believe that every single possible combination of hardware, software, init systems, and even OS kernels should be supported. It isn't impossible for Gentoo to build a moon lander or for the Foundation to buy the entire planet - just hard. However, in practice things that require resources we don't have simply won't happen. Right now having decent KDE and Gnome support with all the bells and whistles that works fine on FreeBSD as well as Linux isn't that hard, because this trend towards vertical integration is just getting started. Running that on OSX under Prefix is already pretty painful (not sure if anybody has actually pulled it off - I'm sure it is possible). It will likely get harder, which means in practice what we'll probably have is a reasonable compromise which will never be quite as polished in any one direction as it could be, unless the end user does the polishing. RE you concerns about OpenRC being in @system. Personally I'm a fan of getting rid of @system entirely except as something used to build install CDs or having some sets for convenience in building systems. It only exists for a few reasons that I can think of: 1. Devs don't want to have ebuilds that capture dependencies on every little thing. A few well-chosen virtuals like shell utilities or whatever might help with this. 2. Things like Prefix rely on the system not installing local copies of libraries in the core system it needs to link to. Careful use of package.provided in profiles might address this. 3. We'd need many more virtuals to handle situations like FreeBSD where people don't what GNU on their systems. Right now if they are system packages they just define system appropriately and ebuilds don't directly pull in the GNU stuff anyway. I'm sure there could be others. Keep in mind that systemd is still pretty new and largely out-of-the-blue so it will take time for Gentoo to adjust to it. Right now OpenRC might install executables, but nothing should be actually running them - this is just wasted compilation time which isn't a bad interim state to be in. If virtualizing udev is causing controversy just wait until somebody actually makes a push to remove OpenRC from @system... Rich
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Wed, 15 Aug 2012 06:27:41 -0400 Rich Freeman ri...@gentoo.org wrote: 1. Devs don't want to have ebuilds that capture dependencies on every little thing. A few well-chosen virtuals like shell utilities or whatever might help with this. Just note that PMS specifies a few requirements about those utilities as well. I'm not sure if we want ebuilds explicitly DEPEND-ing on things which are required by PMS. In any case, virtual/posix-system would be nice to have. 2. Things like Prefix rely on the system not installing local copies of libraries in the core system it needs to link to. Careful use of package.provided in profiles might address this. We could also make virtuals not pull in anything on Prefix in those cases. 3. We'd need many more virtuals to handle situations like FreeBSD where people don't what GNU on their systems. Right now if they are system packages they just define system appropriately and ebuilds don't directly pull in the GNU stuff anyway. I doubt that's a problem. We've got a lot of virtuals and adding new ones shouldn't be a problem. I'd dare say it's better to add more virtuals than introducing USEflags to existing ones -- it requires less work from users. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
On 15-08-2012 12:58:32 +0200, Michał Górny wrote: Rich Freeman ri...@gentoo.org wrote: 2. Things like Prefix rely on the system not installing local copies of libraries in the core system it needs to link to. Careful use of package.provided in profiles might address this. Huh? Not sure I understand this, but it suggests something which isn't true for Prefix to me. We could also make virtuals not pull in anything on Prefix in those cases. Things like virtual/os-headers already do so. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Wed, Aug 15, 2012 at 7:07 AM, Fabian Groffen grob...@gentoo.org wrote: On 15-08-2012 12:58:32 +0200, Michał Górny wrote: Rich Freeman ri...@gentoo.org wrote: 2. Things like Prefix rely on the system not installing local copies of libraries in the core system it needs to link to. Careful use of package.provided in profiles might address this. Huh? Not sure I understand this, but it suggests something which isn't true for Prefix to me. Do you want every other package in the tree depending on glibc, and therefore trying to pull it in on a prefix system? (For those unaware, prefix depends on a non-Gentoo glibc for the system call interface.) There are probably a few ways you could do it, but if you got rid of the implicit @system dependency then you'd need to handle situations where @system is something non-traditional and ebuilds are likely to do it wrong. Agree with mgorny's suggestion that anything required by PMS could be pulled in by the package manager, perhaps in an EAPI-dependent fashion. Oh, @system has another use I didn't mention - getting rid of some chicken-and-egg issues during the initial install. That can be addressed by providing pre-built stage1/2/3s, having package sets and scripts for their building, and so on. Maybe make world a world.d directory with Gentoo providing a starter file and users modifying their own addition, but being free to remove items and depcleaning them. Or provide a syntax for world to remove packages pulled in by a distro-provided world, etc. Many elements of this would benefit from public comment obviously should we choose to go along this road. Rich
Re: [gentoo-dev] Questions about SystemD and OpenRC
On 15-08-2012 07:32:45 -0400, Rich Freeman wrote: On Wed, Aug 15, 2012 at 7:07 AM, Fabian Groffen grob...@gentoo.org wrote: On 15-08-2012 12:58:32 +0200, Michał Górny wrote: Rich Freeman ri...@gentoo.org wrote: 2. Things like Prefix rely on the system not installing local copies of libraries in the core system it needs to link to. Careful use of package.provided in profiles might address this. Huh? Not sure I understand this, but it suggests something which isn't true for Prefix to me. Do you want every other package in the tree depending on glibc, and therefore trying to pull it in on a prefix system? (For those unaware, prefix depends on a non-Gentoo glibc for the system call interface.) Correction: Prefix uses a possibly non-Gentoo, host-provided libc, not necessarily GNU libc of an unknown version. There are only a few packages I've seen that depend on a certain (min/max) version of glibc, and when in use for Prefix, mostly use !prefix? ( elibc_glibc? ( ...) ) stuff at the moment. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen grob...@gentoo.org wrote: There are only a few packages I've seen that depend on a certain (min/max) version of glibc, and when in use for Prefix, mostly use !prefix? ( elibc_glibc? ( ...) ) stuff at the moment. Half the packages in portage link to libc, though they don't actually declare this dependency due to the policy of not declaring policies in @system. If you got rid of @system then they'd need to declare them. However, use of virtuals or package.provided would address this issue - I was just pointing it out. Rich
Re: [gentoo-dev] Questions about SystemD and OpenRC
On 15-08-2012 07:50:42 -0400, Rich Freeman wrote: On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen grob...@gentoo.org wrote: There are only a few packages I've seen that depend on a certain (min/max) version of glibc, and when in use for Prefix, mostly use !prefix? ( elibc_glibc? ( ...) ) stuff at the moment. Half the packages in portage link to libc, though they don't actually declare this dependency due to the policy of not declaring policies in @system. If you got rid of @system then they'd need to declare them. Yeah, so just don't do that. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Wed, Aug 15, 2012 at 06:27:41AM -0400, Rich Freeman wrote: RE you concerns about OpenRC being in @system. Personally I'm a fan of getting rid of @system entirely except as something used to build install CDs or having some sets for convenience in building systems. It only exists for a few reasons that I can think of: 1. Devs don't want to have ebuilds that capture dependencies on every little thing. A few well-chosen virtuals like shell utilities or whatever might help with this. 2. Things like Prefix rely on the system not installing local copies of libraries in the core system it needs to link to. Careful use of package.provided in profiles might address this. 3. We'd need many more virtuals to handle situations like FreeBSD where people don't what GNU on their systems. Right now if they are system packages they just define system appropriately and ebuilds don't directly pull in the GNU stuff anyway. I'm sure there could be others. Keep in mind that systemd is still pretty new and largely out-of-the-blue so it will take time for Gentoo to adjust to it. Right now OpenRC might install executables, but nothing should be actually running them - this is just wasted compilation time which isn't a bad interim state to be in. If virtualizing udev is causing controversy just wait until somebody actually makes a push to remove OpenRC from @system... This isn't in the plans. OpenRC gets installed everywhere right now, because it is a pdepend of baselayout. The plan is actually to tie it to a virtual which will be added to @system; I just haven't gotten around to doing this yet. [1] William [1] https://bugs.gentoo.org/show_bug.cgi?id=409385 pgp04cNZXn8Wa.pgp Description: PGP signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Wed, Aug 15, 2012 at 8:01 AM, Fabian Groffen grob...@gentoo.org wrote: On 15-08-2012 07:50:42 -0400, Rich Freeman wrote: On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen grob...@gentoo.org wrote: There are only a few packages I've seen that depend on a certain (min/max) version of glibc, and when in use for Prefix, mostly use !prefix? ( elibc_glibc? ( ...) ) stuff at the moment. Half the packages in portage link to libc, though they don't actually declare this dependency due to the policy of not declaring policies in @system. If you got rid of @system then they'd need to declare them. Yeah, so just don't do that. In that case then just ignore that whole section of my post. :) Personally I consider the existence of @system a bit of a hack - like the big kernel lock. It works OK, but here and there we run into issues with it. Williamh pointed out that the plan for now is to virtualize openrc/systemd, which certainly is a solution to that problem. Being an evolutionary vs revolutionary solution it is probably the better next step. In fact, if you kept making many steps like that one before long @system would become mostly a big collection of virtuals anyway, and at that point its only reason for being would be as an arbitrary list of packages that ebuild maintainers shouldn't add as dependencies, at which point you could start stripping it away. That isn't unlike what was done to get rid of the big kernel lock - just remove it one instance at a time... Rich
Re: [gentoo-dev] remove system set?
On 15-08-2012 09:43:37 -0400, Rich Freeman wrote: In that case then just ignore that whole section of my post. :) Personally I consider the existence of @system a bit of a hack - like the big kernel lock. It works OK, but here and there we run into issues with it. Williamh pointed out that the plan for now is to virtualize openrc/systemd, which certainly is a solution to that problem. Being an evolutionary vs revolutionary solution it is probably the better next step. In fact, if you kept making many steps like that one before long @system would become mostly a big collection of virtuals anyway, and at that point its only reason for being would be as an arbitrary list of packages that ebuild maintainers shouldn't add as dependencies, at which point you could start stripping it away. That isn't unlike what was done to get rid of the big kernel lock - just remove it one instance at a time... I see it more as the set of packages I need to have on my system/Prefix, to have Portage and its ebuilds working happily and me being able to do basic stuff. One can debate whether ssh belongs to that set. For a non-Prefix (regular Gentoo?) system it's sort of essential, for a Prefix system, it's quite handy to have an ssh that actually works. Nevertheless, the system set, is a vital part of bootstrapping e.g. a Prefix setup. The whole route leading up to the situation of having the full set installed consists of numerous --nodeps emerges carefully put in an order where one can get away with the errors one receives due to missing stuff. From that angle, if you wouldd remove the system set, would you add its contents to the Portage ebuild? Portage itself doesn't need a compiler or might not need gawk, but whatever it runs (ebuilds) often need so. Adding libc, a compiler, linker, shell, etc. to almost any every ebuild looks pretty much useless to me. Adding deps for all regular tools an ebuild uses (bash, sed, awk, cut, wc, ...) seems like error-prone and pretty much useless to me as well. So, there is the system set which just is the central place where those packages are recorded. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
[gentoo-dev] Re: Questions about SystemD and OpenRC
Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted: Right now having decent KDE and Gnome support with all the bells and whistles[...] isn't that hard, [It] will likely get harder, which means in practice what we'll probably have is a reasonable compromise which will never be quite as polished in any one direction as it could be, unless the end user does the polishing. Well stated. RE you concerns about OpenRC being in @system. Personally I'm a fan of getting rid of @system entirely except as something used to build install CDs or having some sets for convenience in building systems. It only exists for a few reasons that I can think of: 1. Devs don't want to have ebuilds that capture dependencies on every little thing. A few well-chosen virtuals like shell utilities or whatever might help with this. 2. Things like Prefix rely on the system not installing local copies of libraries in the core system it needs to link to. Careful use of package.provided in profiles might address this. 3. We'd need many more virtuals to handle situations like FreeBSD where people don't what GNU on their systems. Right now if they are system packages they just define system appropriately and ebuilds don't directly pull in the GNU stuff anyway. AFAIK, @system also helps resolve a few nasty circular dependencies. In fact, I believe that's it's primary purpose. As such I'm not sure it's practical (as opposed to possible, cost/benefit simply makes it impractical) to entirely get rid of, but it does occur to me that sets would be an interesting way to go. Define a few sets that together compose @system as we have it today, and basically package.provide them during the bootstrap phase. AFAIK the original stage tarball also contains a minimal installed tree, for similar reasons. I'm not actually sure how they interact. That'd be releng/arch/catalyst territory. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On Wed, Aug 15, 2012 at 2:21 PM, Duncan 1i5t5.dun...@cox.net wrote: Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted: Right now having decent KDE and Gnome support with all the bells and whistles[...] isn't that hard, [It] will likely get harder, which means in practice what we'll probably have is a reasonable compromise which will never be quite as polished in any one direction as it could be, unless the end user does the polishing. Well stated. RE you concerns about OpenRC being in @system. Personally I'm a fan of getting rid of @system entirely except as something used to build install CDs or having some sets for convenience in building systems. It only exists for a few reasons that I can think of: 1. Devs don't want to have ebuilds that capture dependencies on every little thing. A few well-chosen virtuals like shell utilities or whatever might help with this. 2. Things like Prefix rely on the system not installing local copies of libraries in the core system it needs to link to. Careful use of package.provided in profiles might address this. 3. We'd need many more virtuals to handle situations like FreeBSD where people don't what GNU on their systems. Right now if they are system packages they just define system appropriately and ebuilds don't directly pull in the GNU stuff anyway. AFAIK, @system also helps resolve a few nasty circular dependencies. In fact, I believe that's it's primary purpose. As such I'm not sure it's practical (as opposed to possible, cost/benefit simply makes it impractical) to entirely get rid of, but it does occur to me that sets would be an interesting way to go. Define a few sets that together compose @system as we have it today, and basically package.provide them during the bootstrap phase. AFAIK the original stage tarball also contains a minimal installed tree, for similar reasons. I'm not actually sure how they interact. That'd be releng/arch/catalyst territory. Just piping up here, as this relates to an idea that's been percolating through my mind for a couple weeks. I've occasionally noticed portage tell me about circular dependencies, where the most straight forward resolution is to emerge some package in the loop twice. The first time, with a USE flag disabled (avahi and gtk are the usual suspects), and the second time with the USE flag enabled. In circumstances where it's necessary to do something like that to reach a final desired system state, I'm not sure I see any problem with portage automatically doing the two-stage emerge. It also sounds like something like that could be a benefit to shrinking @system. As far as things such as libc, where many, many packages require their use, I don't personally see a problem with recommending that ebuilds depend on them. My only other notable experience for Linux distributions is Debian/Ubuntu, and a quick glance shows 16,389 packages expressing explicit dependencies on libc6 in Ubuntu 12.04. -- :wq
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On Wed, 15 Aug 2012 15:18:24 -0400 Michael Mol mike...@gmail.com wrote: I've occasionally noticed portage tell me about circular dependencies, where the most straight forward resolution is to emerge some package in the loop twice. The first time, with a USE flag disabled (avahi and gtk are the usual suspects), and the second time with the USE flag enabled. In circumstances where it's necessary to do something like that to reach a final desired system state, I'm not sure I see any problem with portage automatically doing the two-stage emerge. That's going to be rather horrible when your package mangler temporarily turns off acl or turns on build... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On Wed, Aug 15, 2012 at 3:26 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 15 Aug 2012 15:18:24 -0400 Michael Mol mike...@gmail.com wrote: I've occasionally noticed portage tell me about circular dependencies, where the most straight forward resolution is to emerge some package in the loop twice. The first time, with a USE flag disabled (avahi and gtk are the usual suspects), and the second time with the USE flag enabled. In circumstances where it's necessary to do something like that to reach a final desired system state, I'm not sure I see any problem with portage automatically doing the two-stage emerge. That's going to be rather horrible when your package mangler temporarily turns off acl or turns on build... Fair observation; there would need to be a way either weight benign or dangerous USE/package flags, and search paths with weights outside of a 'safe' range would be discarded. A mechanism like that also offers a means of finding and favoring cheap rebuilds over expensive ones; rebuilding gcc an extra time ought to be disfavored over rebuilding, say, sudo. -- :wq
[gentoo-dev] [RFC] new tmpfilesd.eclass
As gentoo switched to /var/run/ - /run in tmpfs recently
people got into problems [1] of missing directories like:
/var/run/screen/
/var/run/openfire/
/var/run/proftpd/
they did bite me personally.
openrc-0.10 brought [2] basic support for systemd's tmpfiles'd:
http://0pointer.de/public/systemd-man/tmpfiles.d.html
But there is no simple way to install such helpers from ebuilds.
The tmpfiles.d is aimed to help in such situations.
I've picked proftpd as an example as it's situation is very similar
to screen's situation. There is inetd mode (opposed to standalone
mode) when you don't have any init.d code to create /var/run/
directories for you. Thus tmpfiles.d for the rescue.
See attach for the whole eclass code. It's almost a copy of Michał's
bash-completion-r1.eclass which I find very easy to use.
I'll show eclass usage example for proftpd:
--- proftpd-1.3.4a-r1.ebuild2012-05-29 20:16:51.0 +0300
+++ proftpd-1.3.4a-r2.ebuild2012-08-15 23:10:49.0 +0300
@@ -3,7 +3,7 @@
# $Header: /var/cvsroot/gentoo-x86/net-ftp/proftpd/proftpd-1.3.4a-r1.ebuild,v
1.2 2012/05/13 10:49:47 swift Exp $
EAPI=4
-inherit eutils
+inherit eutils tmpfilesd
MOD_CASE=0.7
MOD_CLAMAV=0.11rc
@@ -216,6 +216,8 @@
docinto rfc
dodoc doc/rfc/*.txt
fi
+
+ newtmpfilesd ${FILESDIR}/tmpfilesd.conf ${PN}.conf
}
pkg_postinst() {
The caveats:
- files get created only if I run /lib/rc/sh/tmpfiles.sh manually
- haven't tested with systemd, but i'd expect it to work
Thanks!
[1]: https://bugs.gentoo.org/show_bug.cgi?id=361349
[2]: https://bugs.gentoo.org/show_bug.cgi?id=396003
--
Sergei
tmpfilesd.eclass
Description: Binary data
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] new tmpfilesd.eclass
On Wed, 15 Aug 2012 23:57:57 +0300
Sergei Trofimovich sly...@gentoo.org wrote:
But there is no simple way to install such helpers from ebuilds.
The tmpfiles.d is aimed to help in such situations.
Yes, there is.
$ grep dotmpfiles *.eclass
systemd.eclass:# @FUNCTION: systemd_dotmpfilesd
systemd.eclass:systemd_dotmpfilesd() {
Well, it doesn't have a new* variant but I guess that can be added if
necessary.
Also, maybe for some devs a easy make_tmpfiles_d() function will be
useful too...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] new tmpfilesd.eclass
I have a couple of minor requests for readability. Can you call the eclass tmpfiles-d.eclass? Then, for the functions themselves, use names like, dotmpfiles_d newtmpfiles_d so they will be a bit more readable? Thanks, William pgpmBlPbfeN2v.pgp Description: PGP signature
