Re: [gentoo-dev] rfc: virtual/init for init process
On 04/27/2018 11:43 AM, Rich Freeman wrote: > On Fri, Apr 27, 2018 at 2:18 PM Zac Medicowrote: > >> Actually, if things like sys-apps/s6 or sys-process/runit remain as >> choices for virtual/init, this isn't going to solve the problem of >> sys-apps/sysvinit being removed by emerge --depclean. In fact, if >> virtual/init is not in the system set, then emerge --depclean will not >> even warn about removing a system package when it removes > sys-apps/sysvinit. > > Well, at least we don't have to worry about users accidentally uninstalling > openssh, nano, or e2fsprogs (too bad if they use any other filesystem > though). :) > > In general we don't have a great way of telling portage what we're actually > using when various packages do more than one thing. If you have busybox > installed you could conceivably remove a lot of other packages, but most > users don't actually intend for this to happen. > > A USE flag that just pulls in a dep seems like the least evil solution > unless somebody wants to come up with a more general one. A general solution might take the form of a standard interface for interaction between eselect modules and package managers, as discussed in this bug about telling the package manager which kernel you're using: https://bugs.gentoo.org/283587 -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
On Fri, Apr 27, 2018 at 2:18 PM Zac Medicowrote: > Actually, if things like sys-apps/s6 or sys-process/runit remain as > choices for virtual/init, this isn't going to solve the problem of > sys-apps/sysvinit being removed by emerge --depclean. In fact, if > virtual/init is not in the system set, then emerge --depclean will not > even warn about removing a system package when it removes sys-apps/sysvinit. Well, at least we don't have to worry about users accidentally uninstalling openssh, nano, or e2fsprogs (too bad if they use any other filesystem though). :) In general we don't have a great way of telling portage what we're actually using when various packages do more than one thing. If you have busybox installed you could conceivably remove a lot of other packages, but most users don't actually intend for this to happen. A USE flag that just pulls in a dep seems like the least evil solution unless somebody wants to come up with a more general one. -- Rich
Re: [gentoo-dev] rfc: virtual/init for init process
On 04/27/2018 08:45 AM, William Hubbs wrote: > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote: >> On 04/26/2018 11:34 PM, Kent Fredric wrote: >>> On Thu, 26 Apr 2018 13:35:15 -0700 >>> Zac Medicowrote: >>> emerge --depclean, resulting in an unbootable system. Just say-in. >>> >>> And depclean being very verbose doesn't do many favours here either. >>> >>> ( I regularly do >500 package depcleans and spotting things that aren't >>> meant to be >>> culled amongst that list is a bit of a challenge )> >> >> At least for system packages, it will show a warning like the one shown >> here: >> >>https://bugs.gentoo.org/642484#c0 >> >> Hopefully that message helps those that are paying enough attention. >> What can we do for those that overlook the warning message, other than >> give them some rescue instructions for making their system boot again? > > Another option suggested to me was to add a use flag to OpenRC that > pulls in a dependency on virtual/init instead of adding virtual/init to > @system. The suggestion originally was to add it to rdepend, but that > doesn't feel right to me since openrc really doesn't have a runtime > dependency on init, so I'm thinking something like this: > > IUSE="... +separate-init" > > PDEPEND=" > ... > separate-init? ( virtual/init )" > > Thoughts? Actually, if things like sys-apps/s6 or sys-process/runit remain as choices for virtual/init, this isn't going to solve the problem of sys-apps/sysvinit being removed by emerge --depclean. In fact, if virtual/init is not in the system set, then emerge --depclean will not even warn about removing a system package when it removes sys-apps/sysvinit. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
On Fri, Apr 27, 2018 at 1:28 PM, William Hubbswrote: > On Fri, Apr 27, 2018 at 12:28:43PM -0400, Mike Gilbert wrote: >> On Fri, Apr 27, 2018 at 11:45 AM, William Hubbs wrote: >> > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote: >> >> On 04/26/2018 11:34 PM, Kent Fredric wrote: >> >> > On Thu, 26 Apr 2018 13:35:15 -0700 >> >> > Zac Medico wrote: >> >> > >> >> >> emerge --depclean, resulting in an unbootable system. Just say-in. >> >> > >> >> > And depclean being very verbose doesn't do many favours here either. >> >> > >> >> > ( I regularly do >500 package depcleans and spotting things that aren't >> >> > meant to be >> >> > culled amongst that list is a bit of a challenge )> >> >> >> >> At least for system packages, it will show a warning like the one shown >> >> here: >> >> >> >>https://bugs.gentoo.org/642484#c0 >> >> >> >> Hopefully that message helps those that are paying enough attention. >> >> What can we do for those that overlook the warning message, other than >> >> give them some rescue instructions for making their system boot again? >> > >> > Another option suggested to me was to add a use flag to OpenRC that >> > pulls in a dependency on virtual/init instead of adding virtual/init to >> > @system. The suggestion originally was to add it to rdepend, but that >> > doesn't feel right to me since openrc really doesn't have a runtime >> > dependency on init, so I'm thinking something like this: >> > >> > IUSE="... +separate-init" >> > >> > PDEPEND=" >> > ... >> > separate-init? ( virtual/init )" >> > >> > Thoughts? >> >> RDEPEND and PDEPEND have essentially the same meaning when there are >> no cycles in the dependency graph. The devmanual suggests that PDEPEND >> should only be used to avoid cyclic dependencies. >> >> I don't see any reason to prefer PDEPEND over RDEPEND here, and I >> don't understand why that would "feel" better. It effectively gets >> treated as a runtime dependency either way. > > The goal of this is to find a way to accurately reflect the relationship > between openrc and sysvinit in our ebuilds. > > The relationship between openrc and sysvinit is best described as a > configurable reverse runtime dependency which we enable by default -- > sysvinit uses openrc to bring up the system, but openrc itself does not > have a hard dependency on any init provider. > It did in the past, because it called killall5, which is part of > sysvinit, but that has been changed. > > So, the whole relationship is backward in our ebuilds. That, combined > with our distro-wide ban on using use flags for optional runtime > dependencies (also in the devmanual) is why I suggested this. I have no objection to the USE flag idea. Just put the dependency in RDEPEND, not PDEPEND. There is no depgraph cycle to be avoided here.
Re: [gentoo-dev] rfc: virtual/init for init process
On Fri, Apr 27, 2018 at 12:28:43PM -0400, Mike Gilbert wrote: > On Fri, Apr 27, 2018 at 11:45 AM, William Hubbswrote: > > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote: > >> On 04/26/2018 11:34 PM, Kent Fredric wrote: > >> > On Thu, 26 Apr 2018 13:35:15 -0700 > >> > Zac Medico wrote: > >> > > >> >> emerge --depclean, resulting in an unbootable system. Just say-in. > >> > > >> > And depclean being very verbose doesn't do many favours here either. > >> > > >> > ( I regularly do >500 package depcleans and spotting things that aren't > >> > meant to be > >> > culled amongst that list is a bit of a challenge )> > >> > >> At least for system packages, it will show a warning like the one shown > >> here: > >> > >>https://bugs.gentoo.org/642484#c0 > >> > >> Hopefully that message helps those that are paying enough attention. > >> What can we do for those that overlook the warning message, other than > >> give them some rescue instructions for making their system boot again? > > > > Another option suggested to me was to add a use flag to OpenRC that > > pulls in a dependency on virtual/init instead of adding virtual/init to > > @system. The suggestion originally was to add it to rdepend, but that > > doesn't feel right to me since openrc really doesn't have a runtime > > dependency on init, so I'm thinking something like this: > > > > IUSE="... +separate-init" > > > > PDEPEND=" > > ... > > separate-init? ( virtual/init )" > > > > Thoughts? > > RDEPEND and PDEPEND have essentially the same meaning when there are > no cycles in the dependency graph. The devmanual suggests that PDEPEND > should only be used to avoid cyclic dependencies. > > I don't see any reason to prefer PDEPEND over RDEPEND here, and I > don't understand why that would "feel" better. It effectively gets > treated as a runtime dependency either way. The goal of this is to find a way to accurately reflect the relationship between openrc and sysvinit in our ebuilds. The relationship between openrc and sysvinit is best described as a configurable reverse runtime dependency which we enable by default -- sysvinit uses openrc to bring up the system, but openrc itself does not have a hard dependency on any init provider. It did in the past, because it called killall5, which is part of sysvinit, but that has been changed. So, the whole relationship is backward in our ebuilds. That, combined with our distro-wide ban on using use flags for optional runtime dependencies (also in the devmanual) is why I suggested this. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
On Fri, Apr 27, 2018 at 11:45 AM, William Hubbswrote: > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote: >> On 04/26/2018 11:34 PM, Kent Fredric wrote: >> > On Thu, 26 Apr 2018 13:35:15 -0700 >> > Zac Medico wrote: >> > >> >> emerge --depclean, resulting in an unbootable system. Just say-in. >> > >> > And depclean being very verbose doesn't do many favours here either. >> > >> > ( I regularly do >500 package depcleans and spotting things that aren't >> > meant to be >> > culled amongst that list is a bit of a challenge )> >> >> At least for system packages, it will show a warning like the one shown >> here: >> >>https://bugs.gentoo.org/642484#c0 >> >> Hopefully that message helps those that are paying enough attention. >> What can we do for those that overlook the warning message, other than >> give them some rescue instructions for making their system boot again? > > Another option suggested to me was to add a use flag to OpenRC that > pulls in a dependency on virtual/init instead of adding virtual/init to > @system. The suggestion originally was to add it to rdepend, but that > doesn't feel right to me since openrc really doesn't have a runtime > dependency on init, so I'm thinking something like this: > > IUSE="... +separate-init" > > PDEPEND=" > ... > separate-init? ( virtual/init )" > > Thoughts? RDEPEND and PDEPEND have essentially the same meaning when there are no cycles in the dependency graph. The devmanual suggests that PDEPEND should only be used to avoid cyclic dependencies. I don't see any reason to prefer PDEPEND over RDEPEND here, and I don't understand why that would "feel" better. It effectively gets treated as a runtime dependency either way.
Re: [gentoo-dev] rfc: virtual/init for init process
On 04/27/2018 08:43 AM, Pacho Ramos wrote: > El vie, 27-04-2018 a las 00:48 -0700, Zac Medico escribió: >> On 04/26/2018 11:34 PM, Kent Fredric wrote: >>> On Thu, 26 Apr 2018 13:35:15 -0700 >>> Zac Medicowrote: >>> emerge --depclean, resulting in an unbootable system. Just say-in. >>> >>> And depclean being very verbose doesn't do many favours here either. >>> >>> ( I regularly do >500 package depcleans and spotting things that aren't >>> meant to be >>> culled amongst that list is a bit of a challenge )> >> >> At least for system packages, it will show a warning like the one shown >> here: >> >>https://bugs.gentoo.org/642484#c0 >> >> Hopefully that message helps those that are paying enough attention. >> What can we do for those that overlook the warning message, other than >> give them some rescue instructions for making their system boot again? > > Have you think in changing a bit the behavior of depclean to *not* depclean > system packages and ask administrator to do something like "emerge -a > --depclean > --force" to force the depclean of that packages? > > That could help to prevent that mistakes I think I don't want this system packages warning to do anything other that change the display, since it's really based on heuristics. The sysvinit package wouldn't be removed if it was the only provider of virtual/init, and it only triggers the warning because it's the preferred provider. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
On 04/27/2018 08:45 AM, William Hubbs wrote: > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote: >> On 04/26/2018 11:34 PM, Kent Fredric wrote: >>> On Thu, 26 Apr 2018 13:35:15 -0700 >>> Zac Medicowrote: >>> emerge --depclean, resulting in an unbootable system. Just say-in. >>> >>> And depclean being very verbose doesn't do many favours here either. >>> >>> ( I regularly do >500 package depcleans and spotting things that aren't >>> meant to be >>> culled amongst that list is a bit of a challenge )> >> >> At least for system packages, it will show a warning like the one shown >> here: >> >>https://bugs.gentoo.org/642484#c0 >> >> Hopefully that message helps those that are paying enough attention. >> What can we do for those that overlook the warning message, other than >> give them some rescue instructions for making their system boot again? > > Another option suggested to me was to add a use flag to OpenRC that > pulls in a dependency on virtual/init instead of adding virtual/init to > @system. The suggestion originally was to add it to rdepend, but that > doesn't feel right to me since openrc really doesn't have a runtime > dependency on init, so I'm thinking something like this: > > IUSE="... +separate-init" > > PDEPEND=" > ... > separate-init? ( virtual/init )" > > Thoughts? Yes, I like this idea. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote: > On 04/26/2018 11:34 PM, Kent Fredric wrote: > > On Thu, 26 Apr 2018 13:35:15 -0700 > > Zac Medicowrote: > > > >> emerge --depclean, resulting in an unbootable system. Just say-in. > > > > And depclean being very verbose doesn't do many favours here either. > > > > ( I regularly do >500 package depcleans and spotting things that aren't > > meant to be > > culled amongst that list is a bit of a challenge )> > > At least for system packages, it will show a warning like the one shown > here: > >https://bugs.gentoo.org/642484#c0 > > Hopefully that message helps those that are paying enough attention. > What can we do for those that overlook the warning message, other than > give them some rescue instructions for making their system boot again? Another option suggested to me was to add a use flag to OpenRC that pulls in a dependency on virtual/init instead of adding virtual/init to @system. The suggestion originally was to add it to rdepend, but that doesn't feel right to me since openrc really doesn't have a runtime dependency on init, so I'm thinking something like this: IUSE="... +separate-init" PDEPEND=" ... separate-init? ( virtual/init )" Thoughts? William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
El vie, 27-04-2018 a las 00:48 -0700, Zac Medico escribió: > On 04/26/2018 11:34 PM, Kent Fredric wrote: > > On Thu, 26 Apr 2018 13:35:15 -0700 > > Zac Medicowrote: > > > > > emerge --depclean, resulting in an unbootable system. Just say-in. > > > > And depclean being very verbose doesn't do many favours here either. > > > > ( I regularly do >500 package depcleans and spotting things that aren't > > meant to be > > culled amongst that list is a bit of a challenge )> > > At least for system packages, it will show a warning like the one shown > here: > >https://bugs.gentoo.org/642484#c0 > > Hopefully that message helps those that are paying enough attention. > What can we do for those that overlook the warning message, other than > give them some rescue instructions for making their system boot again? Have you think in changing a bit the behavior of depclean to *not* depclean system packages and ask administrator to do something like "emerge -a --depclean --force" to force the depclean of that packages? That could help to prevent that mistakes I think Thanks
Re: [gentoo-dev] rfc: virtual/init for init process
On 04/26/2018 11:34 PM, Kent Fredric wrote: > On Thu, 26 Apr 2018 13:35:15 -0700 > Zac Medicowrote: > >> emerge --depclean, resulting in an unbootable system. Just say-in. > > And depclean being very verbose doesn't do many favours here either. > > ( I regularly do >500 package depcleans and spotting things that aren't meant > to be > culled amongst that list is a bit of a challenge )> At least for system packages, it will show a warning like the one shown here: https://bugs.gentoo.org/642484#c0 Hopefully that message helps those that are paying enough attention. What can we do for those that overlook the warning message, other than give them some rescue instructions for making their system boot again? -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
On Thu, 26 Apr 2018 13:35:15 -0700 Zac Medicowrote: > emerge --depclean, resulting in an unbootable system. Just say-in. And depclean being very verbose doesn't do many favours here either. ( I regularly do >500 package depcleans and spotting things that aren't meant to be culled amongst that list is a bit of a challenge ) pgp6tsEuwaAev.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
On 04/26/2018 01:08 PM, William Hubbs wrote: > After some discussion on IRC, I need to drop busybox from this virtual > because it is in packages already. OpenRC needs to be dropped because > for now we do not have a way to make sure both openrc and sysvinit get > installed in stage 3 if openrc is listed both in virtual/init and > virtual/service-manager. I predict that a non-zero number of users that have sys-apps/s6 or sys-process/runit will accidentally/blindly remove sys-apps/sysvinit via emerge --depclean, resulting in an unbootable system. Just say-in. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
After some discussion on IRC, I need to drop busybox from this virtual because it is in packages already. OpenRC needs to be dropped because for now we do not have a way to make sure both openrc and sysvinit get installed in stage 3 if openrc is listed both in virtual/init and virtual/service-manager. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
Here is the latest version of this virtual based on feedback from the list so far. I have added some providers and cleaned up IUSE. Thanks, William # Copyright 1999-2018 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 EAPI=6 DESCRIPTION="virtual for process 1" SLOT="0" KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt" IUSE="selinux" RDEPEND=" !prefix? ( kernel_linux? ( || ( >=sys-apps/sysvinit-2.86-r6[selinux?] sys-apps/busybox[selinux?] sys-apps/openrc[selinux?] sys-apps/s6 sys-apps/systemd[selinux?] sys-process/runit ) selinux? ( >=sec-policy/selinux-base-policy-2.20170204-r4 ) ) kernel_FreeBSD? ( sys-freebsd/freebsd-sbin ) )" signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
On Wed, Apr 25, 2018 at 3:20 PM, William Hubbswrote: > Hi all, > > In the past, openrc has had a dependency on sysvvinit because it called > killall5. Since it doesn't do that any more, I have been asked to remove > the dependency [1]. Another advantage of doing this is that people will > be able to build profiles without an init package, for containers for > example. > > To do this, I need to add virtual/init for packages that have an init > process.then add virtual/init to profiles/base/packages. > > Please proofread virtual/init as attached before I add it to the tree. If this is really intended to pull in any program that could feasibly be used as PID 1, there are probably multiple providers missing. A couple off the top of my head: sys-apps/busybox sys-apps/openrc (openrc-init) If the virtual is meant to represent something else (as I suspect it is), please elaborate.
Re: [gentoo-dev] rfc: virtual/init for init process
W dniu czw, 26.04.2018 o godzinie 16∶46 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Thu, 26 Apr 2018, Jason Zaman wrote: > > > IUSE="" > > Dont you need: > > IUSE="prefix selinux kernel_linux kernel_FreeBSD" > > prefix and KERNEL are injected from profiles/base/make.defaults, so no > need to have them in IUSE. Still, explicit is better than implicit, especially when there's no harm from being explicit. > > selinux might be needed indeed. > > Ulrich -- Best regards, Michał Górny
Re: [gentoo-dev] rfc: virtual/init for init process
> On Thu, 26 Apr 2018, Jason Zaman wrote: >> IUSE="" > Dont you need: > IUSE="prefix selinux kernel_linux kernel_FreeBSD" prefix and KERNEL are injected from profiles/base/make.defaults, so no need to have them in IUSE. selinux might be needed indeed. Ulrich pgpowgaanGKEE.pgp Description: PGP signature
Re: [gentoo-dev] rfc: virtual/init for init process
On Wed, Apr 25, 2018 at 02:20:29PM -0500, William Hubbs wrote: > Hi all, > > In the past, openrc has had a dependency on sysvvinit because it called > killall5. Since it doesn't do that any more, I have been asked to remove > the dependency [1]. Another advantage of doing this is that people will > be able to build profiles without an init package, for containers for > example. > > To do this, I need to add virtual/init for packages that have an init > process. then add virtual/init to profiles/base/packages. > > Please proofread virtual/init as attached before I add it to the tree. > > Thanks, > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=599468 > > > # Copyright 1999-2018 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > > EAPI=6 > > DESCRIPTION="virtual for process 1" > > SLOT="0" > KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc > x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux > ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris > ~x64-solaris ~x86-solaris ~x86-winnt" > IUSE="" Dont you need: IUSE="prefix selinux kernel_linux kernel_FreeBSD" > RDEPEND=" > !prefix? ( > kernel_linux? ( > || ( > >=sys-apps/sysvinit-2.86-r6[selinux?] > sys-apps/systemd For consistency with the one above, this should probably be sys-apps/systemd[selinux?] -- Jason > ) > selinux? ( > >=sec-policy/selinux-base-policy-2.20170204-r4 > ) > ) > kernel_FreeBSD? ( > sys-freebsd/freebsd-sbin > ) > )"
[gentoo-dev] rfc: virtual/init for init process
Hi all, In the past, openrc has had a dependency on sysvvinit because it called killall5. Since it doesn't do that any more, I have been asked to remove the dependency [1]. Another advantage of doing this is that people will be able to build profiles without an init package, for containers for example. To do this, I need to add virtual/init for packages that have an init process.then add virtual/init to profiles/base/packages. Please proofread virtual/init as attached before I add it to the tree. Thanks, William [1] https://bugs.gentoo.org/show_bug.cgi?id=599468 # Copyright 1999-2018 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 EAPI=6 DESCRIPTION="virtual for process 1" SLOT="0" KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt" IUSE="" RDEPEND=" !prefix? ( kernel_linux? ( || ( >=sys-apps/sysvinit-2.86-r6[selinux?] sys-apps/systemd ) selinux? ( >=sec-policy/selinux-base-policy-2.20170204-r4 ) ) kernel_FreeBSD? ( sys-freebsd/freebsd-sbin ) )" signature.asc Description: Digital signature