Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Dnia 2014-02-12, o godz. 00:39:14
Alex Alexander wi...@gentoo.org napisał(a):
Some developers choose to follow the Gnome team's highlights, while others
choose to go their own way. The QA team would like to establish a guideline
that solves this problem in the best way possible.
First of all, I think that the policy on a flag related to GTK+ should
be set by the GTK+ maintainer, that is the GNOME team, and not directly
by QA.
If people dislike the policy set by GNOME, they can appeal to QA, sure.
But IMO afterwards QA should either give their blessing to the current
GNOME policy or tell GNOME to change the policy, not step in front of
them with a 'higher instance override'.
During our discussion, it was pointed out that keeping a generic USE=gtk is
sub-optimal. The non-straightforward nature of new toolkit versions makes
transitioning from one to the other a slow, tedius process and we think that a
non-versioned USE flag makes things even worse.
How does the flag exactly do that? I don't seem to get the point
in that paragraph.
To achieve this, version 3 of gtk should always be enabled by USE=gtk3. At
some point in the future, when gtk2 consumers reach zero, we will retire gtk
for good. Then, if some day gtk4 comes around, we will be able to introduce
support for it in the tree by simply adding USE=gtk4, without having to
re-structure half the tree.
This goes exactly against the policy that is being established e.g. for
USE=ssl. If QA is really supposed to set a policy here, it should set
a generic policy for all those cases.
USE flags should represent *features*, not tools used to implement
them. If users want SSL support in an application, they want to set
USE=ssl and stop caring. Not look through all the USE flags in case
application used USE=openssl, USE=gnutls, USE=polarssl etc. for it.
Multiple USE flags make sense when there's support for multiple
toolkits that works and is maintained, and the user may reasonably want
to switch between them. But then, the extra USE flags for toolkit
switching should be introduced with keeping USE=ssl as the generic
on/off switch and the specific flags an optional implementation switch
for power users.
In the end, GTK+ is much the same. You want GTK+ GUI, you enable
USE=gtk. You need specific switching between 2 and 3, assuming it is
*reasonable and well supported*, you can use extra USE=gtk2 or
USE=gtk3. This generally works, and causes issues mostly to complainers
alike 'I dislike this, I want to be able to easily mask it all'.
I don't think there's a point messing up the general case for the sake
of complainers that will either end up enabling USE=gtk3 anyway at some
point or end up without a GUI.
That said, I'm all for killing most of USE=gtk, USE=wxwidgets, USE=qt*
occurrences with a generic USE=gui following the earlier principle.
If user installs an application and wants a GUI for it, shklee
shouldn't have to care whether it's GTK+, wxWidgets or Qt. Gentoo
should be a distribution friendly to all toolkits, people who collect
applications specific to a single toolkit belong in {,k,x}ubuntu.
Then, the special USE flags make sense for fine-picking one
of the toolkits when multiple are supported.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett creff...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote: Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages that may support either or both the toolkits. To handle this, a few developers have introduced the gtk3 useflag, that prefers gtk3 over gtk2 when both toolkit versions are supported. At this point, the Gnome team highly recommends prefering gtk3 if possible, skipping the useflag altogether. [1] Wrong, as is written in policy whether to prefer gtk2 or 3 is up to the maintainer of the package. We point people to the fact that upstream says gtk2 is a dead end and support will stop (if not in fact already stopped) in the near future. We also recommend to have maintainers support slots for their libs where possible considering man-power and to only choose one toolkit for applications considering where upstream development is going and maturity of the port, and again, this is up to package maintainers. This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. Except when you end up rebuilding the huge thing twice. Or trying to live with binpackages -- the thing that most Gentoo developers don't care about at all. They just love their precious USE flags so much they'd shove them everywhere for the sake of it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Le mardi 11 février 2014 à 19:33 -0500, Chris Reffett a écrit : This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. And here comes the version abuse troll again. This discussion was settled months ago by exhaustion so please do not try to put some gasoline on it. Most packages we have been confronted to chose to only support gtk2 or gtk3 and if in their history the supported gtk2 then gtk3, we need a slot for that because it makes sense. See gnome-desktop, glade, gtkhtml, at-spi, libgda, gucharmap, vte, etc. For those packages that still support both actively, we still want slots because most packages we have seen (webkit-gtk, gtk-vnc, spice and more that since lost their gtk2 support) only allowed building against one toolkit at a time. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Le mercredi 12 février 2014 à 08:29 +0100, Lars Wendler a écrit : [...] This is a really good idea and I am all in favor of it. gtk+:3 still isn't adopted widely and there are still not many good looking skins available for it. (sorry but I don't want to have all gtk+ apps I am using looking totally ugly again) I doubt gtk+:2 will be deprecated that soon as some of our devs try to imply. We do not pretend anything, we read upstream statements in bug reports and in blogs. I do not keep them bookmarked though but do not get your hopes too high, it will be slow, but as sure as Gnome 2 is going to be removed from the tree, gtk2 is not evolving anymore and receives as little maintenance as possible by upstream (which in software development means it is rusting and the conclusion should be evident to anyone). Of course, just as gtk1 we are not going to remove it right now. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/wmbattery: ChangeLog wmbattery-2.42.ebuild wmbattery-2.19-r1.ebuild
Le 12/02/2014 1:02, Samuli Suominen a écrit :
On 12/02/14 01:20, Bernard Cafarelli wrote:
Le Tue, 11 Feb 2014 12:09:14 +0200
Samuli Suominen ssuomi...@gentoo.org a écrit:
On 11/02/14 11:42, Bernard Cafarelli (voyageur) wrote:
voyageur14/02/11 09:42:47
Modified: ChangeLog
Added:wmbattery-2.42.ebuild
Removed: wmbattery-2.19-r1.ebuild
Log:
Version bump, adds upower support
(Portage version: 2.2.8-r1/cvs/Linux x86_64, signed Manifest
commit with key C74525F2)
Revision ChangesPath
1.24 x11-plugins/wmbattery/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?r1=1.23r2=1.24
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ChangeLog 25 Sep 2012 14:08:40 - 1.23
+++ ChangeLog 11 Feb 2014 09:42:47 - 1.24
@@ -1,6 +1,12 @@
# ChangeLog for x11-plugins/wmbattery
-# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL
v2
-# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.23
2012/09/25 14:08:40 voyageur Exp $
+# Copyright 1999-2014 Gentoo Foundation; Distributed under the GPL
v2
+# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.24
2014/02/11 09:42:47 voyageur Exp $
+
+*wmbattery-2.42 (11 Feb 2014)
+
+ 11 Feb 2014; Bernard Cafarelli voyag...@gentoo.org
+ -wmbattery-2.19-r1.ebuild, +wmbattery-2.42.ebuild:
+ Version bump, adds upower support
*wmbattery-2.41 (25 Sep 2012)
1.1 x11-plugins/wmbattery/wmbattery-2.42.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1content-type=text/plain
Index: wmbattery-2.42.ebuild
===
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild,v
1.1 2014/02/11 09:42:47 voyageur Exp $
EAPI=5
inherit autotools
DESCRIPTION=A dockable app to report APM, ACPI, or SPIC battery
status
HOMEPAGE=http://joeyh.name/code/wmbattery/;
SRC_URI=mirror://debian/pool/main/w/${PN}/${PN}_${PV}.tar.gz
LICENSE=GPL-2
SLOT=0
KEYWORDS=~amd64 ~ppc -sparc ~x86
IUSE=
DEPEND=sys-apps/apmd
sys-power/upower
x11-libs/libX11
x11-libs/libXext
x11-libs/libXpm
Are you sure there are no runtime dependencies at all?
Futhermore, does it really link against the upower libraries or just
call it only at RDEPEND through dbus?
In any case, the deps are wrong.
Nice catch, also present in the previous bump! 2.40 used EAPI 3 so it
had the implicit RDEPEND=${DEPEND}... Fixed in both 2.41 and 2.42
ebuilds
For upower this new version directly uses upower-glib, so it's a build
dependency
I don't think it's legit to use the upower-glib library without
pkg-config. So I'm pretty sure you are missing build-time-only
dependency of virtual/pkgconfig then too.
Indeed:
% grep 'pkg-config.*upower'
/var/tmp/portage/x11-plugins/wmbattery-2.42/work/wmbattery/Makefile
LIBS+=$(shell pkg-config --libs upower-glib)
$(CC) $(CPPFLAGS) $(CFLAGS) $(shell pkg-config --cflags upower-glib) -c
upower.c -o upower.o
Dependency added, thanks!
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On Wed, 12 Feb 2014 09:05:59 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2014-02-12, o godz. 00:39:14 Alex Alexander wi...@gentoo.org napisał(a): Some developers choose to follow the Gnome team's highlights, while others choose to go their own way. The QA team would like to establish a guideline that solves this problem in the best way possible. First of all, I think that the policy on a flag related to GTK+ should be set by the GTK+ maintainer, that is the GNOME team, and not directly by QA. The GNOME team has already made a recommendation on this; and feel free to correct me, but I think they internally regard it as a policy the GNOME team itself has to apply. If people dislike the policy set by GNOME, they can appeal to QA, sure. This is what indirectly happens here; hasufell brought this up to us, as people are closing bugs blocking below tracker as RESOLVED WONTFIX: https://bugs.gentoo.org/show_bug.cgi?id=420493 An overview of the bugs blocking this tracker: https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL%20blocked%3A420493 But IMO afterwards QA should either give their blessing to the current GNOME policy or tell GNOME to change the policy, not step in front of them with a 'higher instance override'. We've brought leio early into the discussion during the QA team meeting; as it currently stands, I think this is still a recommendation which makes it easier for people to object it. We've planned to bring this out to the mailing list (as wired did), as well as clarify the objections to it; in an attempt to listen and then discuss and work with the GNOME team on making this work for everyone. During our discussion, it was pointed out that keeping a generic USE=gtk is sub-optimal. The non-straightforward nature of new toolkit versions makes transitioning from one to the other a slow, tedius process and we think that a non-versioned USE flag makes things even worse. How does the flag exactly do that? I don't seem to get the point in that paragraph. What do we think the flag does? There are multiple ways to interpret gtk - Add support for x11-libs/gtk+ (The GIMP Toolkit) if you want to; and depending on that, there are underlying difficulties that pop up. Does it cover one slot or all slots? If it covers one slot, should it be named after that slot instead? If it covers multiple slots, quoting leio: Why don't we just rename it to USE=gui? Other people more acknowledged with that can probably explain it more well, but realistically the USE flag description should explain this more clear such that we don't need to explain it; now, consider this: Why is there no USE=qt for Qt? Why do we not need it there? To achieve this, version 3 of gtk should always be enabled by USE=gtk3. At some point in the future, when gtk2 consumers reach zero, we will retire gtk for good. Then, if some day gtk4 comes around, we will be able to introduce support for it in the tree by simply adding USE=gtk4, without having to re-structure half the tree. This goes exactly against the policy that is being established e.g. for USE=ssl. If QA is really supposed to set a policy here, it should set a generic policy for all those cases. USE flags should represent *features*, not tools used to implement them. If users want SSL support in an application, they want to set USE=ssl and stop caring. Not look through all the USE flags in case application used USE=openssl, USE=gnutls, USE=polarssl etc. for it. Exactly, I think this backs up the USE=gui idea above. [TL;DR: Skip the next two paragraphs, we're agreeing on that; I just left it in for if anyone wants to read it for furtherer understanding.] As for the versioned USE=gtk3, ...; I'm wondering how the user would then specify what to build for, or even worse: If a package depends on gtk+ without a SLOT and was build against gtk3, then the user wants to support gtk4 as well but hold on to gtk3 until all his packages work with gtk4, how would you reflect that in the ebuild? I see USE=gtk -- USE=gui as a good idea; however, for a reason like the above where control as to which GTK version is supported (benefits changed USE flag rebuilds) is needed by the user are affected if we decide to do something about the versioned USE=gtk3, ... Multiple USE flags make sense when there's support for multiple toolkits that works and is maintained, and the user may reasonably want to switch between them. But then, the extra USE flags for toolkit switching should be introduced with keeping USE=ssl as the generic on/off switch and the specific flags an optional implementation switch for power users. In the end, GTK+ is much the same. You want GTK+ GUI, you enable USE=gtk. You need specific switching between 2 and 3, assuming it is *reasonable and well supported*, you can use extra USE=gtk2 or USE=gtk3. Sorry; should have read further before writing my previous quote response, there's agreement here to
[gentoo-dev] Re: mbox -- looks sort of interesting
On 02/12/2014 04:56 PM, Brian Dolbec wrote: On Wed, 12 Feb 2014 01:36:01 +1100 Michael Palimaka kensing...@gentoo.org wrote: On 02/12/2014 01:03 AM, Rich Freeman wrote: On Tue, Feb 11, 2014 at 7:39 AM, Michael Palimaka kensing...@gentoo.org wrote: On 02/11/2014 11:34 PM, Rich Freeman wrote: One of those ideas I've always wanted to implement is to create a portage hook/patch that looks at the dependencies for the package being built and configures sandbox to block read-access to anything that wasn't explicitly declared. Sandbox works for read-access as well as write-access, though in /etc/sandbox.d/00default read-access is enabled everywhere by default. And, yes, it could be configured to allow access to @system... That's pretty much what emerge_strict does. What is emerge_strict? The Google is failing me here... Rich Sorry, I should have clarified. It's provided by autodep, extending the dependency analysis by denying access to any files not part of the specified dependencies and @system. There was a gentoo gsoc project a few years ago that did exactly this for doing dep checks on ebuilds. There was also one for determining deps automatically. Is this the project mentioned? ^^^ Should be, autodep was GSoC 2011.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/wmbattery: ChangeLog wmbattery-2.42.ebuild wmbattery-2.19-r1.ebuild
On 12/02/14 10:57, Bernard Cafarelli wrote:
Le 12/02/2014 1:02, Samuli Suominen a écrit :
On 12/02/14 01:20, Bernard Cafarelli wrote:
Le Tue, 11 Feb 2014 12:09:14 +0200
Samuli Suominen ssuomi...@gentoo.org a écrit:
On 11/02/14 11:42, Bernard Cafarelli (voyageur) wrote:
voyageur14/02/11 09:42:47
Modified: ChangeLog
Added:wmbattery-2.42.ebuild
Removed: wmbattery-2.19-r1.ebuild
Log:
Version bump, adds upower support
(Portage version: 2.2.8-r1/cvs/Linux x86_64, signed Manifest
commit with key C74525F2)
Revision ChangesPath
1.24 x11-plugins/wmbattery/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?rev=1.24content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/ChangeLog?r1=1.23r2=1.24
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ChangeLog25 Sep 2012 14:08:40 -1.23
+++ ChangeLog11 Feb 2014 09:42:47 -1.24
@@ -1,6 +1,12 @@
# ChangeLog for x11-plugins/wmbattery
-# Copyright 1999-2012 Gentoo Foundation; Distributed under the
GPL v2
-# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.23
2012/09/25 14:08:40 voyageur Exp $
+# Copyright 1999-2014 Gentoo Foundation; Distributed under the
GPL v2
+# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/ChangeLog,v 1.24
2014/02/11 09:42:47 voyageur Exp $
+
+*wmbattery-2.42 (11 Feb 2014)
+
+ 11 Feb 2014; Bernard Cafarelli voyag...@gentoo.org
+ -wmbattery-2.19-r1.ebuild, +wmbattery-2.42.ebuild:
+ Version bump, adds upower support
*wmbattery-2.41 (25 Sep 2012)
1.1 x11-plugins/wmbattery/wmbattery-2.42.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild?rev=1.1content-type=text/plain
Index: wmbattery-2.42.ebuild
===
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/x11-plugins/wmbattery/wmbattery-2.42.ebuild,v
1.1 2014/02/11 09:42:47 voyageur Exp $
EAPI=5
inherit autotools
DESCRIPTION=A dockable app to report APM, ACPI, or SPIC battery
status
HOMEPAGE=http://joeyh.name/code/wmbattery/;
SRC_URI=mirror://debian/pool/main/w/${PN}/${PN}_${PV}.tar.gz
LICENSE=GPL-2
SLOT=0
KEYWORDS=~amd64 ~ppc -sparc ~x86
IUSE=
DEPEND=sys-apps/apmd
sys-power/upower
x11-libs/libX11
x11-libs/libXext
x11-libs/libXpm
Are you sure there are no runtime dependencies at all?
Futhermore, does it really link against the upower libraries or just
call it only at RDEPEND through dbus?
In any case, the deps are wrong.
Nice catch, also present in the previous bump! 2.40 used EAPI 3 so it
had the implicit RDEPEND=${DEPEND}... Fixed in both 2.41 and 2.42
ebuilds
For upower this new version directly uses upower-glib, so it's a build
dependency
I don't think it's legit to use the upower-glib library without
pkg-config. So I'm pretty sure you are missing build-time-only
dependency of virtual/pkgconfig then too.
Indeed:
% grep 'pkg-config.*upower'
/var/tmp/portage/x11-plugins/wmbattery-2.42/work/wmbattery/Makefile
LIBS+=$(shell pkg-config --libs upower-glib)
$(CC) $(CPPFLAGS) $(CFLAGS) $(shell pkg-config --cflags
upower-glib) -c upower.c -o upower.o
Dependency added, thanks!
One more thing, why does it depend on sys-apps/apmd (which is part of
the old hotplug base that got replaced by acpi in 1995'ish) ?
It is really a hardcoded dependency after gained upower support? Seems
crazy, I don't think APM is used in any modern machines.
I don't think Linux kernel even supports APM since version 3.3.0 anymore
fully...
- Samuli
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On 2/12/2014 3:09 AM, Michał Górny wrote: Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett creff...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote: Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages that may support either or both the toolkits. To handle this, a few developers have introduced the gtk3 useflag, that prefers gtk3 over gtk2 when both toolkit versions are supported. At this point, the Gnome team highly recommends prefering gtk3 if possible, skipping the useflag altogether. [1] Wrong, as is written in policy whether to prefer gtk2 or 3 is up to the maintainer of the package. We point people to the fact that upstream says gtk2 is a dead end and support will stop (if not in fact already stopped) in the near future. We also recommend to have maintainers support slots for their libs where possible considering man-power and to only choose one toolkit for applications considering where upstream development is going and maturity of the port, and again, this is up to package maintainers. This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. Except when you end up rebuilding the huge thing twice. Or trying to live with binpackages -- the thing that most Gentoo developers don't care about at all. They just love their precious USE flags so much they'd shove them everywhere for the sake of it. You'll have to build it twice anyway, this just splits it into two separate packages, and I suspect that the times where you will have to rebuild are when a package needs webkit-gtk to support another toolkit (which should happen only once), and when you upgrade (in which case you would be updating them separately anyway). I also fail to see what this has to do with binpkgs: if something needs webkit-gtk[gtk2], you add a dep on webkit-gtk[gtk2]. The user adds USE=gtk2 to webkit-gtk if needed, webkit-gtk binpkg gets rebuilt. I see no breakage there. Chris Reffett
[gentoo-dev] Last rites: x11-plugins/desklet-sudoku
# Dion Moult mo...@gentoo.org (13 Feb 2014) # Masked for removal in 30 days. Unclear license, desklets dead. (bug #446776) x11-plugins/desklet-sudoku -- Dion Moult
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Le mercredi 12 février 2014 à 17:46 -0500, Chris Reffett a écrit : splits it into two separate packages, and I suspect that the times where you will have to rebuild are when a package needs webkit-gtk to support another toolkit (which should happen only once), and when you upgrade (in which case you would be updating them separately anyway). I also fail to see what this has to do with binpkgs: if something needs webkit-gtk[gtk2], you add a dep on webkit-gtk[gtk2]. The user adds USE=gtk2 to webkit-gtk if needed, webkit-gtk binpkg gets rebuilt. I see no breakage there Actually changing a USE flag on a package such as webkit-gtk has a huge cost. If say you build with USE=gtk3 then suddenly need gtk2, you not only build what you need, you will also have to rebuild gtk3 support which you already have though. Since this takes a decent amount of time, even on a one year old i7, I don't know about you, but I am pretty sure users will start to complain about this as well. You would have to build, webkit1 for gtk2, webkit1 for gtk3 and webkit2 for gtk3. The story is the same for almost all libs that support both toolkits, you end up rebuilding everything even if you already have one. webkit-gtk is just the best example to prove you this is a bad idea. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On Wed, Feb 12, 2014 at 2:46 PM, Chris Reffett creff...@gentoo.org wrote: On 2/12/2014 3:09 AM, Michał Górny wrote: Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett creff...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote: Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages that may support either or both the toolkits. To handle this, a few developers have introduced the gtk3 useflag, that prefers gtk3 over gtk2 when both toolkit versions are supported. At this point, the Gnome team highly recommends prefering gtk3 if possible, skipping the useflag altogether. [1] Wrong, as is written in policy whether to prefer gtk2 or 3 is up to the maintainer of the package. We point people to the fact that upstream says gtk2 is a dead end and support will stop (if not in fact already stopped) in the near future. We also recommend to have maintainers support slots for their libs where possible considering man-power and to only choose one toolkit for applications considering where upstream development is going and maturity of the port, and again, this is up to package maintainers. This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. Except when you end up rebuilding the huge thing twice. Or trying to live with binpackages -- the thing that most Gentoo developers don't care about at all. They just love their precious USE flags so much they'd shove them everywhere for the sake of it. You'll have to build it twice anyway, this just splits it into two separate packages, and I suspect that the times where you will have to rebuild are when a package needs webkit-gtk to support another toolkit (which should happen only once), and when you upgrade (in which case you would be updating them separately anyway). After talking to Chris on IRC, I think we've made progress. I claim that there's a fundamental distinction between USE flags controlling how the binaries are built and controlling *which* binaries are built. I think that the use of SLOTs here is perfectly reasonable, since webkit-gtk installs different libraries (not just the same library with different build options) in the two slots. There's apparently some disdain for using the -r200/-r300 versioning to control the slots, but I think if we want to clean that up we should look at modifying PMS to allow something cleaner.
[gentoo-dev] Re: RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On Wed, 12 Feb 2014 09:10:31 +0100 Gilles Dartiguelongue e...@gentoo.org wrote: Le mardi 11 février 2014 à 19:33 -0500, Chris Reffett a écrit : This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. And here comes the version abuse troll again. This discussion was settled months ago by exhaustion so please do not try to put some gasoline on it. Using arbitrary revision numbers to make up for the fact that you can't install multiple SLOTs of the same version of a package is a fucking travesty. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: mbox -- looks sort of interesting
Hi, It was my project. The portage changed a lot since that time, I can try to renew it, if it's still used. 2014-02-12 17:45 GMT+06:00 Michael Palimaka kensing...@gentoo.org: On 02/12/2014 04:56 PM, Brian Dolbec wrote: On Wed, 12 Feb 2014 01:36:01 +1100 Michael Palimaka kensing...@gentoo.org wrote: On 02/12/2014 01:03 AM, Rich Freeman wrote: On Tue, Feb 11, 2014 at 7:39 AM, Michael Palimaka kensing...@gentoo.org wrote: On 02/11/2014 11:34 PM, Rich Freeman wrote: One of those ideas I've always wanted to implement is to create a portage hook/patch that looks at the dependencies for the package being built and configures sandbox to block read-access to anything that wasn't explicitly declared. Sandbox works for read-access as well as write-access, though in /etc/sandbox.d/00default read-access is enabled everywhere by default. And, yes, it could be configured to allow access to @system... That's pretty much what emerge_strict does. What is emerge_strict? The Google is failing me here... Rich Sorry, I should have clarified. It's provided by autodep, extending the dependency analysis by denying access to any files not part of the specified dependencies and @system. There was a gentoo gsoc project a few years ago that did exactly this for doing dep checks on ebuilds. There was also one for determining deps automatically. Is this the project mentioned? ^^^ Should be, autodep was GSoC 2011.
