Re: [gentoo-dev] [PATCH 3/4] toolchain.eclass: Transition deps to x11-base/xorg-proto
On 4/27/18 2:31 AM, Matt Turner wrote:
> ---
> eclass/toolchain.eclass | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 2da455ad4e3b..df76dc4feb8c 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -206,11 +206,10 @@ DEPEND="${RDEPEND}
> if in_iuse gcj ; then
> GCJ_DEPS=">=media-libs/libart_lgpl-2.1"
> GCJ_GTK_DEPS="
> + x11-base/xorg-proto
> x11-libs/libXt
> x11-libs/libX11
> x11-libs/libXtst
> - x11-proto/xproto
> - x11-proto/xextproto
> =x11-libs/gtk+-2*
> virtual/pkgconfig
> "
>
These patches should be fine. It looks like you just finished
stabilizing x11-base/xorg-proto for all arches so the transition won't
cause any problems.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
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 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? -- Thanks, Zac signature.asc Description: OpenPGP digital signature
[gentoo-dev] Please do not add maintainers without their consent
Hi, TL;DR: please do not add others as maintainers of your packages without asking them first. For example, please stop adding python@ to anything that remotely looks like Python without consent of Python project. The Python team is currently maintaining over 1200 packages. Many of those packages were never touched, reviewed or even ever seen by members of the Python project. For some of them, we ended up as (factual or effective) primary (or only) maintainers even though none of us ever had any clue about the package in question. We maintain packages that have barely any relevance to Python, or fit our 'modus operandi'. This problem is not limited to the Python team. What was my surprise when bugs against outdated libFuzzer package started coming to LLVM project even though nobody has ever even pinged us about that package. Therefore, I would like to ask all developers the following: if you believe we should co-maintain your package, please ask us *first*. Stop adding people without their consent. Thank you. -- Best regards, Michał Górny
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 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? 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 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? William signature.asc Description: 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 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? Yes, I like this idea. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
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 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? > > 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 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.
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 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. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: virtual/init for init process
On Fri, Apr 27, 2018 at 1:28 PM, William Hubbs wrote: > 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 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 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? 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 2:18 PM Zac Medico wrote: > 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 11:43 AM, Rich Freeman wrote: > On Fri, Apr 27, 2018 at 2:18 PM Zac Medico wrote: > >> 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
