[gentoo-dev] [RFC] virtual/polkit-agent virtual pkg
We have actually 3 polkit agent implementations in Portage: gnome-extra/polkit-gnome lxde-base/lxpolkit sys-auth/polkit-kde-agent I guess a virtual is required. Just a simple example, gnome-extra/nm-applet requires a polkit auth agent (not present in RDEPEND atm -- bug!) in order to handle wifi passwords, etc. But the same applet can be used in both GNOME and LXDE, making lxpolkit a better choice over polkit-gnome for the latter. My proposal is to create a virtual pkg listing all the polkit auth agent implementations and make pkgs depend on it. -- Fabio Erculiani
Re: [gentoo-dev] [RFC] virtual/polkit-agent virtual pkg
If user is emerging some polkit-requiring package on DE-less system, it will pull big bunch of KDE, GNOME, etc. pacakges, which is not desired. Also, nm-applet and others can be set up with localauthority files, without help of polkit agents. I don't think virtual will solve this case.
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Sun, Apr 3, 2011 at 1:20 PM, Corentin Chary wrote: > Hi again, Found a little problem: it's not finding a newer version of wireless-regdb, which uses a date-based versioning system. If euscan tried to view/parse the directory index where the distfiles are located, it would find this new file. http://euscan.iksaif.net/package/net-wireless/wireless-regdb/ Matt
[gentoo-dev] rfc: using /libexec
All, we just got the following bug report for openrc today [1]. On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this causes breakage in openrc. The simplest fix for this would be for us to add /libexec to baselayout and start using it for platform-agnostic code. We have /usr/libexec, so I don't know why we don't have /libexec. Should we? William [1] http://bugs.gentoo.org/show_bug.cgi?id=381783 pgp82InMxPfUM.pgp Description: PGP signature
Re: [gentoo-dev] rfc: using /libexec
On Tue, 6 Sep 2011 13:46:06 -0500 William Hubbs wrote: > we just got the following bug report for openrc today [1]. > > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this > causes breakage in openrc. > > The simplest fix for this would be for us to add /libexec to > baselayout and start using it for platform-agnostic code. We > have /usr/libexec, so I don't know why we don't have /libexec. Should > we? We don't have it because we usually don't want to introduce additional directories in rootfs. Honestly, I'd rather see all stuff go to /usr than introducing /libexec. Other solution is finally to migrate to a multilib solution with no symlinks. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: using /libexec
On Tue, Sep 06, 2011 at 09:20:38PM +0200, Michał Górny wrote: > On Tue, 6 Sep 2011 13:46:06 -0500 > William Hubbs wrote: > > > we just got the following bug report for openrc today [1]. > > > > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this > > causes breakage in openrc. > > > > The simplest fix for this would be for us to add /libexec to > > baselayout and start using it for platform-agnostic code. We > > have /usr/libexec, so I don't know why we don't have /libexec. Should > > we? > > We don't have it because we usually don't want to introduce additional > directories in rootfs. Honestly, I'd rather see all stuff go to /usr > than introducing /libexec. openrc cannot be installed in /usr, because it is used to boot the system. Also remember that openrc is not used on linux systems only, so we can't blindly assume that everyone would be fine with us moving it to /usr. William pgpXpRpRKqBh3.pgp Description: PGP signature
Re: [gentoo-dev] rfc: using /libexec
Hi, On Tue, 2011-09-06 at 13:46 -0500, William Hubbs wrote: > we just got the following bug report for openrc today [1]. The solution to that bug is probably to use /lib*/.. instead of /lib/... as the path you use ? > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this > causes breakage in openrc. That sounds like an openrc bug to me. > The simplest fix for this would be for us to add /libexec to baselayout > and start using it for platform-agnostic code. We have /usr/libexec, so > I don't know why we don't have /libexec. Should we? /usr/libexec is not for platform-agnostic code, it is for platform dependant executables that are not meant to be executed directly by the user. /usr/lib/X/Y and /usr/libexec/Y should be exactly the same. You may want to put all the executables in /usr/libexec anyway, as having separate / and /usr is a outdated idea anyway, and most of the other distros will make that completely impossible very soon. Be bold. Fedora is even going to make /lib, /bin and /sbin symlinks to /usr. My 2 cents (as the guy who made the /lib->/lib64 link in the first place). -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: gentoo-x86/dev-libs/libffi: ChangeLog libffi-3.0.10_rc8.ebuild libffi-3.0.9.ebuild
On 06-09-2011 20:24:54 +, Samuli Suominen wrote: > Modified: ChangeLog > Removed: libffi-3.0.10_rc8.ebuild libffi-3.0.9.ebuild > Log: > [This is a placeholder. Please ignore.] Considering that you seem to do this on a regular basis: Please change your script to write something less useless. This message is in any case, now and in the future, useless to look at. We know your opinion by now. Stop doing this, please. Alternative message suggestion: remove old ebuilds > --- ChangeLog 29 Aug 2011 17:40:29 - 1.125 > +++ ChangeLog 6 Sep 2011 20:24:54 - 1.126 > @@ -1,6 +1,10 @@ > # ChangeLog for dev-libs/libffi > # Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2 > + > + 06 Sep 2011; Samuli Suominen -libffi-3.0.9.ebuild, > + -libffi-3.0.10_rc8.ebuild: > + [This is a placeholder. Please ignore.] -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: using /libexec
On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote: > we just got the following bug report for openrc today [1]. > > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this > causes breakage in openrc. that specific report sounds like using /run would fix things ? as for the paths, openrc should be using the paths it installs into. so if we're installing into /lib64/rc..., then that's what we should be using. > The simplest fix for this would be for us to add /libexec to baselayout > and start using it for platform-agnostic code. We have /usr/libexec, so > I don't know why we don't have /libexec. Should we? same answer as last time people have asked about /libexec: no. we dont need it, and it's ugly cruft that no other distro ive seen uses, and this isnt something we need to differentiate Gentoo. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: using /libexec
On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote: > On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote: > > we just got the following bug report for openrc today [1]. > > > > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this > > causes breakage in openrc. > > that specific report sounds like using /run would fix things ? I haven't really looked at using /run for anything in openrc on linux, but that might be possible once we have it installed in baselayout. I don't think it would fix this issue though. > as for the paths, openrc should be using the paths it installs into. so if > we're installing into /lib64/rc..., then that's what we should be using. We are installing into /lib/rc, but /lib is a symlink on 64 bit systems, so we are having an issue resolving the path. > > The simplest fix for this would be for us to add /libexec to baselayout > > and start using it for platform-agnostic code. We have /usr/libexec, so > > I don't know why we don't have /libexec. Should we? > > same answer as last time people have asked about /libexec: no. we dont need > it, and it's ugly cruft that no other distro ive seen uses, and this isnt > something we need to differentiate Gentoo. The same thing should be applied to /usr/libexec then shouldn't it? (just asking for more info here) William pgpppTp23sjmE.pgp Description: PGP signature
Re: [gentoo-dev] rfc: using /libexec
On Tue, Sep 06, 2011 at 04:45:43PM -0500, William Hubbs wrote: > On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote: > > On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote: > > > we just got the following bug report for openrc today [1]. > > > > > > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this > > > causes breakage in openrc. > > > > that specific report sounds like using /run would fix things ? > > I haven't really looked at using /run for anything in openrc on linux, > but that might be possible once we have it installed in baselayout. > > I don't think it would fix this issue though. Looking at this again, you are right, if rc_svcdir was /run/openrc, there would no longer be an issue. So, can you please fix baselayout to install /run? http://bugs.gentoo.org/361349 Thanks much, William pgptZdF8FiwPn.pgp Description: PGP signature
Re: [gentoo-dev] rfc: using /libexec
On Tue, 2011-09-06 at 16:45 -0500, William Hubbs wrote: > On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote: > > On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote: > > > The simplest fix for this would be for us to add /libexec to baselayout > > > and start using it for platform-agnostic code. We have /usr/libexec, so > > > I don't know why we don't have /libexec. Should we? > > > > same answer as last time people have asked about /libexec: no. we dont > > need > > it, and it's ugly cruft that no other distro ive seen uses, and this isnt > > something we need to differentiate Gentoo. > > The same thing should be applied to /usr/libexec then shouldn't it? > (just asking for more info here) /usr/libexec is used by almost all major distros (except Debian), it has been standardin Red Hat since before the FHS existed. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: using /libexec
On Tuesday, September 06, 2011 17:58:12 Olivier Crête wrote: > On Tue, 2011-09-06 at 16:45 -0500, William Hubbs wrote: > > On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote: > > > On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote: > > > > The simplest fix for this would be for us to add /libexec to > > > > baselayout and start using it for platform-agnostic code. We have > > > > /usr/libexec, so I don't know why we don't have /libexec. Should we? > > > > > > same answer as last time people have asked about /libexec: no. we dont > > > need it, and it's ugly cruft that no other distro ive seen uses, and > > > this isnt something we need to differentiate Gentoo. > > > > The same thing should be applied to /usr/libexec then shouldn't it? > > (just asking for more info here) > > /usr/libexec is used by almost all major distros (except Debian), it has > been standardin Red Hat since before the FHS existed. and i think Debian is sane for not following ;) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: using /libexec
On Tuesday, September 06, 2011 17:53:37 William Hubbs wrote: > On Tue, Sep 06, 2011 at 04:45:43PM -0500, William Hubbs wrote: > > On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote: > > > On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote: > > > > we just got the following bug report for openrc today [1]. > > > > > > > > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and > > > > this causes breakage in openrc. > > > > > > that specific report sounds like using /run would fix things ? > > > > I haven't really looked at using /run for anything in openrc on linux, > > but that might be possible once we have it installed in baselayout. > > > > I don't think it would fix this issue though. > > Looking at this again, you are right, if rc_svcdir was /run/openrc, > there would no longer be an issue. > > So, can you please fix baselayout to install /run? yes, i guess i can stop dragging my feet on this since it seems that every other distro is going this route as well -mike signature.asc Description: This is a digitally signed message part.
