Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: > On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: > > On Wed, 06 Jun 2012 21:16:05 +0200 > > Pacho Ramos wrote: > >> Well, I think reading this thread is more or less clear what it would > >> be supposed to do, also Zac suggested it and looks to have an idea > >> about what should it do. > > > > There's a big leap from "more or less clear" and "an idea" to the kind > > of knowledge we want to have. Think REQUIRED_USE for how this can go > > wrong... > > > > If you think ABI_SLOT is essential, why not try implementing it and > > trying it out in a large number of packages, and reporting your results? > > It's pretty close to the SLOT operator model, and it seems like it > should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and > test it in an overlay before we include it in the final EAPI 5. I'd prefer you nailing down the details a bit more before slipping it into an EAPI called "5_pre1"; aside from usual complaints, frankly I'd rather not have to figure out the design of it via raiding the patches out of portage history ;) If we're going to do this, there should be a way to represent the direction of compatibility. Might be overthinking it, but consider upgrades where new API is added; this does *not* break ABI, it extends it. Going in reverse however *would* break ABI for anything that was using the new additions. This issue can be avoided via usage of version operators w/ appropriate slot binding deps, just seems hanky in light of what we're talking about. I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing in '06/'07); I'd however suggest ensuring there is some buy in from devs on that one since that was the main argument against it in the past. That argument may no longer apply, but should be checked imo. ~harring
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 14:59 -0700, Brian Harring escribió: > On Tue, Jun 05, 2012 at 07:18:01PM -0700, Zac Medico wrote: > > On 06/05/2012 05:51 PM, Michael Weber wrote: > > > Is there any chance to detect this ZLIB_VERSION problem with > > > revdep-rebuild (worst case: add a list of possibly broken packages > > > with tests)? > > > > I'd suggest a special ebuild phase to check for ABI changes, like the > > pre_pkg_preinst_abi_check phase suggested here: > > > > https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 > > Same thing I said in '07; I don't have a problem w/ hooks for ebuilds > to specify additional QA checks, but this *cannot* be the user's end > solution- it needs to be purely for making it easier for devs to spot > their screwups. In other words, revdep-rebuild shouldn't be involved; > this should spot/complain that zlib (for example) changed abi w/out a > matching metadata setting/whatever, rather than having checks done in > the consumers. > > Using this for anything other than a QA check of the originating > package, basically has an end result of us going towards a > non-deterministic resolution model- which is a clusterfuck, frankly. > > ~harring > > Personally, my intention was exactly that: use that check to allow devs to detect the problem and commit a proper ebuild (this test could even be fatal to really enforce developers to not miss it) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/kid3: metadata.xml kid3-2.1.ebuild ChangeLog
On 06/07/2012 04:06 PM, Michael Palimaka (kensington) wrote:
kensington12/06/07 13:06:48
Modified: metadata.xml ChangeLog
Added:kid3-2.1.ebuild
Log:
Version bump. Add upstream metadata.
(Portage version: 2.1.10.65/cvs/Linux x86_64)
Revision ChangesPath
1.5 media-sound/kid3/metadata.xml
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/metadata.xml?rev=1.5&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/metadata.xml?rev=1.5&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/metadata.xml?r1=1.4&r2=1.5
Index: metadata.xml
===
RCS file: /var/cvsroot/gentoo-x86/media-sound/kid3/metadata.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- metadata.xml21 Aug 2009 14:36:01 - 1.4
+++ metadata.xml7 Jun 2012 13:06:48 - 1.5
@@ -3,4 +3,12 @@
kde
sound
+
+Enable support for acoustic fingerprinting plugin using
+ (media-libs/chromaprint)
+
+
+http://sourceforge.net/tracker/?group_id=70849
+kid3
+
1.61 media-sound/kid3/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/ChangeLog?rev=1.61&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/ChangeLog?rev=1.61&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/ChangeLog?r1=1.60&r2=1.61
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/media-sound/kid3/ChangeLog,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- ChangeLog 19 May 2012 09:07:30 - 1.60
+++ ChangeLog 7 Jun 2012 13:06:48 - 1.61
@@ -1,6 +1,12 @@
# ChangeLog for media-sound/kid3
# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/media-sound/kid3/ChangeLog,v 1.60
2012/05/19 09:07:30 ssuominen Exp $
+# $Header: /var/cvsroot/gentoo-x86/media-sound/kid3/ChangeLog,v 1.61
2012/06/07 13:06:48 kensington Exp $
+
+*kid3-2.1 (07 Jun 2012)
+
+ 07 Jun 2012; Michael Palimaka +kid3-2.1.ebuild,
+ metadata.xml:
+ Version bump. Add upstream metadata.
19 May 2012; Samuli Suominen kid3-1.4.ebuild,
kid3-2.0.1.ebuild:
1.1 media-sound/kid3/kid3-2.1.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/kid3-2.1.ebuild?rev=1.1&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/kid3-2.1.ebuild?rev=1.1&content-type=text/plain
Index: kid3-2.1.ebuild
===
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/media-sound/kid3/kid3-2.1.ebuild,v 1.1
2012/06/07 13:06:48 kensington Exp $
EAPI=4
KDE_LINGUAS="cs de es et fi fr it nl pl ru sr sr@ijekavian sr@ijekavianlatin sr@Latn
tr zh_TW"
KDE_REQUIRED="always"
KDE_HANDBOOK="optional"
inherit kde4-base
DESCRIPTION="A simple tag editor for KDE"
HOMEPAGE="http://kid3.sourceforge.net/";
SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
LICENSE="GPL-2"
SLOT="4"
KEYWORDS="~amd64 ~x86"
IUSE="chroma flac mp3 mp4 +taglib vorbis"
RDEPEND="
chroma? (
media-libs/chromaprint
virtual/ffmpeg
)
flac? (
media-libs/flac[cxx]
media-libs/libvorbis
)
mp3? ( media-libs/id3lib )
mp4? ( media-libs/libmp4v2:0 )
taglib? ( media-libs/taglib )
vorbis? (
media-libs/libogg
media-libs/libvorbis
)"
DEPEND="${RDEPEND}"
REQUIRED_USE="flac? ( vorbis )"
src_configure() {
local mycmakeargs=(
$(cmake-utils_use_with chroma CHROMAPRINT)
$(cmake-utils_use_with flac)
$(cmake-utils_use_with mp3 ID3LIB)
$(cmake-utils_use_with mp4 MP4V2)
$(cmake-utils_use_with vorbis)
$(cmake-utils_use_with taglib)
"-DWITH_TUNEPIMP=OFF"
"-DWITH_KDE=ON"
No such flag as WITH_TUNEPIMP in 2.1 release anymore.
And the build system should now work so that USE="kde" can be added with
KDE_REQUIRED=optional.
(I was writing ebuild for this too, and it looks very much like what you
have except these 2 issues.)
- Samuli
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/kid3: metadata.xml kid3-2.1.ebuild ChangeLog
On 2012-06-07 23:06, Samuli Suominen wrote:
On 06/07/2012 04:06 PM, Michael Palimaka (kensington) wrote:
kensington 12/06/07 13:06:48
Modified: metadata.xml ChangeLog
Added: kid3-2.1.ebuild
Log:
Version bump. Add upstream metadata.
(Portage version: 2.1.10.65/cvs/Linux x86_64)
Revision Changes Path
1.5 media-sound/kid3/metadata.xml
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/metadata.xml?rev=1.5&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/metadata.xml?rev=1.5&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/metadata.xml?r1=1.4&r2=1.5
Index: metadata.xml
===
RCS file: /var/cvsroot/gentoo-x86/media-sound/kid3/metadata.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- metadata.xml 21 Aug 2009 14:36:01 - 1.4
+++ metadata.xml 7 Jun 2012 13:06:48 - 1.5
@@ -3,4 +3,12 @@
kde
sound
+
+ Enable support for acoustic fingerprinting
plugin using
+ (media-libs/chromaprint)
+
+
+ http://sourceforge.net/tracker/?group_id=70849
+ kid3
+
1.61 media-sound/kid3/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/ChangeLog?rev=1.61&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/ChangeLog?rev=1.61&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/ChangeLog?r1=1.60&r2=1.61
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/media-sound/kid3/ChangeLog,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- ChangeLog 19 May 2012 09:07:30 - 1.60
+++ ChangeLog 7 Jun 2012 13:06:48 - 1.61
@@ -1,6 +1,12 @@
# ChangeLog for media-sound/kid3
# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/media-sound/kid3/ChangeLog,v 1.60
2012/05/19 09:07:30 ssuominen Exp $
+# $Header: /var/cvsroot/gentoo-x86/media-sound/kid3/ChangeLog,v 1.61
2012/06/07 13:06:48 kensington Exp $
+
+*kid3-2.1 (07 Jun 2012)
+
+ 07 Jun 2012; Michael Palimaka +kid3-2.1.ebuild,
+ metadata.xml:
+ Version bump. Add upstream metadata.
19 May 2012; Samuli Suominen kid3-1.4.ebuild,
kid3-2.0.1.ebuild:
1.1 media-sound/kid3/kid3-2.1.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/kid3-2.1.ebuild?rev=1.1&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/kid3-2.1.ebuild?rev=1.1&content-type=text/plain
Index: kid3-2.1.ebuild
===
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/media-sound/kid3/kid3-2.1.ebuild,v
1.1 2012/06/07 13:06:48 kensington Exp $
EAPI=4
KDE_LINGUAS="cs de es et fi fr it nl pl ru sr sr@ijekavian
sr@ijekavianlatin sr@Latn tr zh_TW"
KDE_REQUIRED="always"
KDE_HANDBOOK="optional"
inherit kde4-base
DESCRIPTION="A simple tag editor for KDE"
HOMEPAGE="http://kid3.sourceforge.net/";
SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
LICENSE="GPL-2"
SLOT="4"
KEYWORDS="~amd64 ~x86"
IUSE="chroma flac mp3 mp4 +taglib vorbis"
RDEPEND="
chroma? (
media-libs/chromaprint
virtual/ffmpeg
)
flac? (
media-libs/flac[cxx]
media-libs/libvorbis
)
mp3? ( media-libs/id3lib )
mp4? ( media-libs/libmp4v2:0 )
taglib? ( media-libs/taglib )
vorbis? (
media-libs/libogg
media-libs/libvorbis
)"
DEPEND="${RDEPEND}"
REQUIRED_USE="flac? ( vorbis )"
src_configure() {
local mycmakeargs=(
$(cmake-utils_use_with chroma CHROMAPRINT)
$(cmake-utils_use_with flac)
$(cmake-utils_use_with mp3 ID3LIB)
$(cmake-utils_use_with mp4 MP4V2)
$(cmake-utils_use_with vorbis)
$(cmake-utils_use_with taglib)
"-DWITH_TUNEPIMP=OFF"
"-DWITH_KDE=ON"
No such flag as WITH_TUNEPIMP in 2.1 release anymore.
Good catch, thanks for noticing.
And the build system should now work so that USE="kde" can be added with
KDE_REQUIRED=optional.
I did test that, however was unable to make it work correctly. YMMV.
(I was writing ebuild for this too, and it looks very much like what you
have except these 2 issues.)
Great minds think alike. ;-)
- Samuli
Michael
Re: [gentoo-dev] x32 release candidate
On Thursday 07 June 2012 02:13:16 Luca Barbato wrote: > On 07/06/12 05:17, Mike Frysinger wrote: > > On Wednesday 06 June 2012 15:40:18 Gregory M. Turner wrote: > >> Is there a wiki or forum thread somewhere where folks can gloat and/or > >> commiserate? > > > > i haven't set up anything > > Shall we start a http://wiki.gentoo.org/wiki/amd64-x32 page? assuming our wiki is sane and can handle namespaces, i'd go with: http://wiki.gentoo.org/wiki/amd64/x32 -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 01:24 AM, Brian Harring wrote: > On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: >> On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: >>> On Wed, 06 Jun 2012 21:16:05 +0200 >>> Pacho Ramos wrote: Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. >>> >>> There's a big leap from "more or less clear" and "an idea" to the kind >>> of knowledge we want to have. Think REQUIRED_USE for how this can go >>> wrong... >>> >>> If you think ABI_SLOT is essential, why not try implementing it and >>> trying it out in a large number of packages, and reporting your results? >> >> It's pretty close to the SLOT operator model, and it seems like it >> should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and >> test it in an overlay before we include it in the final EAPI 5. > > I'd prefer you nailing down the details a bit more before slipping it > into an EAPI called "5_pre1"; aside from usual complaints, frankly I'd > rather not have to figure out the design of it via raiding the patches > out of portage history ;) Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe we can convince him to change it to ABI_SLOT operators. > If we're going to do this, there should be a way to represent > the direction of compatibility. Might be overthinking it, but > consider upgrades where new API is added; this does *not* break ABI, > it extends it. Going in reverse however *would* break ABI for > anything that was using the new additions. This issue can be avoided > via usage of version operators w/ appropriate slot binding deps, just > seems hanky in light of what we're talking about. That might be nice, but it also complicates things a bit. We might stand a better chance of getting Ciaran to cooperate if we keep it simpler and stay closer to the SLOT operator model. > I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing in > '06/'07); I'd however suggest ensuring there is some buy in from devs > on that one since that was the main argument against it in the past. I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 10:28 PM, Ciaran McCreesh wrote: > On Wed, 06 Jun 2012 14:21:40 -0700 > Zac Medico wrote: >>> You'd have a slot per ABI, and be encouraged to allow multiple >>> versions of glib to be installed in parallel. If you really >>> couldn't do that (and you should think very carefully before saying >>> you can't, since this directly affects users in a huge way), you >>> can make the slots block each other. >> >> It seems like you're trying to make glib fit your SLOT operator model, >> even though it's a natural fit for the ABI_SLOT operator model. > > No, I'm trying to strongly encourage people to make proper use of slots > to avoid having mass breakages and annoyances on user systems, even if > it means more work for developers. But aren't you also trying to make them deviate from upstreams' release models? > Broken linkage due to an upgrade really shouldn't happen. It's certainly not ideal, but wouldn't it be useful to have the flexibility to accommodate it? Let's be practical. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico wrote: > I can imagine that ABI_SLOT operator deps will be a lot more popular > than SLOT operator deps, since ABI_SLOT operator deps will accommodate > the common practice of allowing ABI changes within a particular SLOT. You're missing out on a brilliant opportunity to encourage developers put in a bit more work to save users a huge amount of pain here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 11:12 PM, Ciaran McCreesh wrote: > On Wed, 06 Jun 2012 14:45:55 -0700 > Zac Medico wrote: >> Can you explain how Exherbo is handling dbus-glib rebuilds after >> glib:2 updates? > > Badly, most likely. And, I suspect that they'd be handling with ABI_SLOT operator deps, if they were available. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 18:40 +0100, Ciaran McCreesh escribió: > On Thu, 07 Jun 2012 09:43:32 -0700 > Zac Medico wrote: > > I can imagine that ABI_SLOT operator deps will be a lot more popular > > than SLOT operator deps, since ABI_SLOT operator deps will accommodate > > the common practice of allowing ABI changes within a particular SLOT. > > You're missing out on a brilliant opportunity to encourage developers > put in a bit more work to save users a huge amount of pain here. > Won't be possible to encourage developers to make that "bit" more work when that work is not so "bit". Of course, I understand there are probably some valid cases when situation can (and should) be improved, but I still fail to see the advantage of allowing parallel installation for glib, xorg-server... taking care their reverse dependencies simply need a rebuild to work with latest ABIs and, then, users should anyway need to remove that old slots once reverse deps are rebuilt against latest slot as we wouldn't support setups where people is lazy to rebuild and have, for example, x11 drivers built against xorg-server-1.9.5-r1 even having 1.11.2-r2 installed in parallel. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 10:42 -0700, Zac Medico escribió: > On 06/06/2012 10:28 PM, Ciaran McCreesh wrote: > > On Wed, 06 Jun 2012 14:21:40 -0700 > > Zac Medico wrote: > >>> You'd have a slot per ABI, and be encouraged to allow multiple > >>> versions of glib to be installed in parallel. If you really > >>> couldn't do that (and you should think very carefully before saying > >>> you can't, since this directly affects users in a huge way), you > >>> can make the slots block each other. > >> > >> It seems like you're trying to make glib fit your SLOT operator model, > >> even though it's a natural fit for the ABI_SLOT operator model. > > > > No, I'm trying to strongly encourage people to make proper use of slots > > to avoid having mass breakages and annoyances on user systems, even if > > it means more work for developers. > > But aren't you also trying to make them deviate from upstreams' release > models? > > > Broken linkage due to an upgrade really shouldn't happen. > > It's certainly not ideal, but wouldn't it be useful to have the > flexibility to accommodate it? Let's be practical. Also think we are not able to fix that broken linkage problems alone, even distributions supplying precompiled packages need to rebuild their packages against latest version due that breakages before releasing new packages to the users. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 10:40 AM, Ciaran McCreesh wrote: > On Thu, 07 Jun 2012 09:43:32 -0700 > Zac Medico wrote: >> I can imagine that ABI_SLOT operator deps will be a lot more popular >> than SLOT operator deps, since ABI_SLOT operator deps will accommodate >> the common practice of allowing ABI changes within a particular SLOT. > > You're missing out on a brilliant opportunity to encourage developers > put in a bit more work to save users a huge amount of pain here. What about cases like the dbus-glib and glib:2 dependency, where it's just too much trouble to use SLOT operator deps? Wouldn't it be better to have a little flexibility, so that we can accommodate more packages? As a workaround for SLOT operator deps, I suppose that glib:1 could be split into a separate glib-legacy package, in order to facilitate the use of SLOT operator dependencies in dbus-glib. That way, it would be easy to match glib-2.x and not have to worry about trying not to match glib-1.x. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico wrote: > On 06/07/2012 01:24 AM, Brian Harring wrote: > > On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: > >> On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: > >>> On Wed, 06 Jun 2012 21:16:05 +0200 > >>> Pacho Ramos wrote: > Well, I think reading this thread is more or less clear what it > would be supposed to do, also Zac suggested it and looks to have > an idea about what should it do. > >>> > >>> There's a big leap from "more or less clear" and "an idea" to the > >>> kind of knowledge we want to have. Think REQUIRED_USE for how > >>> this can go wrong... > >>> > >>> If you think ABI_SLOT is essential, why not try implementing it > >>> and trying it out in a large number of packages, and reporting > >>> your results? > >> > >> It's pretty close to the SLOT operator model, and it seems like it > >> should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, > >> and test it in an overlay before we include it in the final EAPI 5. > > > > I'd prefer you nailing down the details a bit more before slipping > > it into an EAPI called "5_pre1"; aside from usual complaints, > > frankly I'd rather not have to figure out the design of it via > > raiding the patches out of portage history ;) > > Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe > we can convince him to change it to ABI_SLOT operators. > Whether we can convince Ciaran to change the wording of a feature in a draft document is utterly irrelevant. SLOT operator deps solve a large class of issues and wont get in the way of solving the ranged dep problem in a later step, be it ABI_SLOT or something more generic. I'm all for getting SLOT operators into EAPI-5 as actually already intended for earlier EAPIs. EAPI 5 was supposed to be a quick EAPI so don't let us delay the whole thing because of that. > > If we're going to do this, there should be a way to represent > > the direction of compatibility. Might be overthinking it, but > > consider upgrades where new API is added; this does *not* break > > ABI, it extends it. Going in reverse however *would* break ABI for > > anything that was using the new additions. This issue can be > > avoided via usage of version operators w/ appropriate slot binding > > deps, just seems hanky in light of what we're talking about. > > That might be nice, but it also complicates things a bit. We might > stand a better chance of getting Ciaran to cooperate if we keep it > simpler and stay closer to the SLOT operator model. > Again, it's not about getting someone to cooperate. Something that you comment with "that might be nice" isn't ready for inclusion into EAPI 5. > > I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing > > in '06/'07); I'd however suggest ensuring there is some buy in from > > devs on that one since that was the main argument against it in the > > past. > > I can imagine that ABI_SLOT operator deps will be a lot more popular > than SLOT operator deps, since ABI_SLOT operator deps will accommodate > the common practice of allowing ABI changes within a particular SLOT. What for? So we won't ever get rid of revdep-rebuild resp. @preserved-libs? Except for the ranged dep problem I don't see any additional benefit but potential drawbacks. Please correct me where I'm wrong. Cheers. signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07.06.2012 19:47, Zac Medico wrote: > And, I suspect that they'd be handling with ABI_SLOT operator deps, > if they were available. No, we wouldn't. Best regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/Q7TgACgkQnuVXRcSi+5qDGwCgyRCGz13xuzCCB0htW4IalqJM eqIAn2lJRsfQUcoJ+B/iYioyPhN7oU0C =tZkw -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 11:03:25 -0700 Zac Medico wrote: > > You're missing out on a brilliant opportunity to encourage > > developers put in a bit more work to save users a huge amount of > > pain here. > > What about cases like the dbus-glib and glib:2 dependency, where it's > just too much trouble to use SLOT operator deps? Wouldn't it be better > to have a little flexibility, so that we can accommodate more > packages? Then if it really is "too much trouble", which is another way of saying "it's a thousand times more work for a developer to get it right than it is for a user to deal with it", you can use blockers. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 10:42:29 -0700 Zac Medico wrote: > >> It seems like you're trying to make glib fit your SLOT operator > >> model, even though it's a natural fit for the ABI_SLOT operator > >> model. > > > > No, I'm trying to strongly encourage people to make proper use of > > slots to avoid having mass breakages and annoyances on user > > systems, even if it means more work for developers. > > But aren't you also trying to make them deviate from upstreams' > release models? Only if upstream are cowboys who go out of their way to make it hard to slot things. > > Broken linkage due to an upgrade really shouldn't happen. > > It's certainly not ideal, but wouldn't it be useful to have the > flexibility to accommodate it? Let's be practical. Blockers plus SLOT provides that flexibility. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 20:04 +0200, Wulf C. Krueger escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07.06.2012 19:47, Zac Medico wrote: > > And, I suspect that they'd be handling with ABI_SLOT operator deps, > > if they were available. > > No, we wouldn't. > > Best regards, Wulf Talk by yourself please signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 11:03 -0700, Zac Medico escribió: > On 06/07/2012 10:40 AM, Ciaran McCreesh wrote: > > On Thu, 07 Jun 2012 09:43:32 -0700 > > Zac Medico wrote: > >> I can imagine that ABI_SLOT operator deps will be a lot more popular > >> than SLOT operator deps, since ABI_SLOT operator deps will accommodate > >> the common practice of allowing ABI changes within a particular SLOT. > > > > You're missing out on a brilliant opportunity to encourage developers > > put in a bit more work to save users a huge amount of pain here. > > What about cases like the dbus-glib and glib:2 dependency, where it's > just too much trouble to use SLOT operator deps? Wouldn't it be better > to have a little flexibility, so that we can accommodate more packages? > > As a workaround for SLOT operator deps, I suppose that glib:1 could be > split into a separate glib-legacy package, in order to facilitate the > use of SLOT operator dependencies in dbus-glib. That way, it would be > easy to match glib-2.x and not have to worry about trying not to match > glib-1.x. I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 10:47:19 -0700 Zac Medico wrote: > On 06/06/2012 11:12 PM, Ciaran McCreesh wrote: > > On Wed, 06 Jun 2012 14:45:55 -0700 > > Zac Medico wrote: > >> Can you explain how Exherbo is handling dbus-glib rebuilds after > >> glib:2 updates? > > > > Badly, most likely. > > And, I suspect that they'd be handling with ABI_SLOT operator deps, if > they were available. Nope. They'd be handling it with something known as 'parts' (which is a way of removing a subset of an installed package's contents and turning off a subset of its option flags), plus SLOT and option dependencies. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 11:04 AM, Ralph Sennhauser wrote: > On Thu, 07 Jun 2012 09:43:32 -0700 > Zac Medico wrote: > >> On 06/07/2012 01:24 AM, Brian Harring wrote: >>> On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: > On Wed, 06 Jun 2012 21:16:05 +0200 > Pacho Ramos wrote: >> Well, I think reading this thread is more or less clear what it >> would be supposed to do, also Zac suggested it and looks to have >> an idea about what should it do. > > There's a big leap from "more or less clear" and "an idea" to the > kind of knowledge we want to have. Think REQUIRED_USE for how > this can go wrong... > > If you think ABI_SLOT is essential, why not try implementing it > and trying it out in a large number of packages, and reporting > your results? It's pretty close to the SLOT operator model, and it seems like it should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and test it in an overlay before we include it in the final EAPI 5. >>> >>> I'd prefer you nailing down the details a bit more before slipping >>> it into an EAPI called "5_pre1"; aside from usual complaints, >>> frankly I'd rather not have to figure out the design of it via >>> raiding the patches out of portage history ;) >> >> Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe >> we can convince him to change it to ABI_SLOT operators. >> > > Whether we can convince Ciaran to change the wording of a feature in a > draft document is utterly irrelevant. > > SLOT operator deps solve a large class of issues and wont get in the > way of solving the ranged dep problem in a later step, be it ABI_SLOT > or something more generic. > > I'm all for getting SLOT operators into EAPI-5 as actually already > intended for earlier EAPIs. EAPI 5 was supposed to be a quick EAPI so > don't let us delay the whole thing because of that. Delay doesn't concern be so much. If SLOT operator deps are the best that we can all agree on for now though, then I can accept that. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 11:13 AM, Ciaran McCreesh wrote: > On Thu, 07 Jun 2012 10:47:19 -0700 > Zac Medico wrote: >> On 06/06/2012 11:12 PM, Ciaran McCreesh wrote: >>> On Wed, 06 Jun 2012 14:45:55 -0700 >>> Zac Medico wrote: Can you explain how Exherbo is handling dbus-glib rebuilds after glib:2 updates? >>> >>> Badly, most likely. >> >> And, I suspect that they'd be handling with ABI_SLOT operator deps, if >> they were available. > > Nope. They'd be handling it with something known as 'parts' (which is a > way of removing a subset of an installed package's contents and turning > off a subset of its option flags), plus SLOT and option dependencies. That sounds nice. Maybe we can do that in EAPI 6. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 20:16 +0200, Pacho Ramos escribió: > El jue, 07-06-2012 a las 11:03 -0700, Zac Medico escribió: > > On 06/07/2012 10:40 AM, Ciaran McCreesh wrote: > > > On Thu, 07 Jun 2012 09:43:32 -0700 > > > Zac Medico wrote: > > >> I can imagine that ABI_SLOT operator deps will be a lot more popular > > >> than SLOT operator deps, since ABI_SLOT operator deps will accommodate > > >> the common practice of allowing ABI changes within a particular SLOT. > > > > > > You're missing out on a brilliant opportunity to encourage developers > > > put in a bit more work to save users a huge amount of pain here. > > > > What about cases like the dbus-glib and glib:2 dependency, where it's > > just too much trouble to use SLOT operator deps? Wouldn't it be better > > to have a little flexibility, so that we can accommodate more packages? > > > > As a workaround for SLOT operator deps, I suppose that glib:1 could be > > split into a separate glib-legacy package, in order to facilitate the > > use of SLOT operator dependencies in dbus-glib. That way, it would be > > easy to match glib-2.x and not have to worry about trying not to match > > glib-1.x. > > I would prefer, as a workaround, allow reverse deps to RDEPEND on > glib:2.* instead. That way it would cover more cases when more than two > slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like "*" usage for SLOTs would be allowed :), or I am misinterpreting it? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos wrote: > > I would prefer, as a workaround, allow reverse deps to RDEPEND on > > glib:2.* instead. That way it would cover more cases when more than > > two slots are available > > Well, per: > http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b > > looks like "*" usage for SLOTs would be allowed :), or I am > misinterpreting it? It's not a wildcard. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: > On Thu, 07 Jun 2012 20:43:54 +0200 > Pacho Ramos wrote: > > > I would prefer, as a workaround, allow reverse deps to RDEPEND on > > > glib:2.* instead. That way it would cover more cases when more than > > > two slots are available > > > > Well, per: > > http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b > > > > looks like "*" usage for SLOTs would be allowed :), or I am > > misinterpreting it? > > It's not a wildcard. > But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep "SLOT" over "ABI_SLOT" (at least for this case, not sure about others I could be missing now...) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 12:00 PM, Pacho Ramos wrote: > El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: >> On Thu, 07 Jun 2012 20:43:54 +0200 >> Pacho Ramos wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available >>> >>> Well, per: >>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b >>> >>> looks like "*" usage for SLOTs would be allowed :), or I am >>> misinterpreting it? >> >> It's not a wildcard. >> > > But it looks like a valid usage for cases like glib vs. > dbus-glib/gobject-introspection I have exposed as example, and also > allows us to keep "SLOT" over "ABI_SLOT" (at least for this case, not > sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/06/12 03:00 PM, Pacho Ramos wrote: > El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: >> On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos >> wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available >>> >>> Well, per: >>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b >>> >>> >>> looks like "*" usage for SLOTs would be allowed :), or I am >>> misinterpreting it? >> >> It's not a wildcard. >> > > But it looks like a valid usage for cases like glib vs. > dbus-glib/gobject-introspection I have exposed as example, and > also allows us to keep "SLOT" over "ABI_SLOT" (at least for this > case, not sure about others I could be missing now...) How is the case of something like libpng going to be handled, where we only support one API (and so only one SLOT)? Either in the proposed ABI_SLOT thing or when using slot operators? For the slot-operator case, will every consumer of libpng be forced to change their dep to libpng:= to ensure they get rebuilt when libpng bumps from 1.5 to 1.6?? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/Q/XsACgkQ2ugaI38ACPCxWQEAgkx7C2PBK/awXvfA3RFolZQD 2K7G7cBboDvDexn/JogA/0W/ke62zz7Mtk/i6WLATIaUYRQ+8ViK2Y4J8n4C3yVZ =SQX9 -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 07 Jun 2012 15:14:03 -0400 Ian Stakenvicius wrote: > How is the case of something like libpng going to be handled, where we > only support one API (and so only one SLOT)? Either in the proposed > ABI_SLOT thing or when using slot operators? Ideally, by you putting in the work and supporting more than one API, since doing so vastly improves the user experience. Failing that, SLOT plus blockers. Then if it turns out that really doesn't work (and it's not just developers being utterly lazy), either ABI_SLOT or parts in a future EAPI. > For the slot-operator case, will every consumer of libpng be forced to > change their dep to libpng:= to ensure they get rebuilt when libpng > bumps from 1.5 to 1.6?? Every consumer of libpng that wants to improve from the current situation, yes. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/Q/dMACgkQ96zL6DUtXhFlgQCaAr/9xTL8/bwTHbqud5ETo1fN T64An077XiZVmdP+/76KBTdRVlaDa4U2 =se/J -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: > On 06/07/2012 12:00 PM, Pacho Ramos wrote: > > El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: > >> On Thu, 07 Jun 2012 20:43:54 +0200 > >> Pacho Ramos wrote: > I would prefer, as a workaround, allow reverse deps to RDEPEND on > glib:2.* instead. That way it would cover more cases when more than > two slots are available > >>> > >>> Well, per: > >>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b > >>> > >>> looks like "*" usage for SLOTs would be allowed :), or I am > >>> misinterpreting it? > >> > >> It's not a wildcard. > >> > > > > But it looks like a valid usage for cases like glib vs. > > dbus-glib/gobject-introspection I have exposed as example, and also > > allows us to keep "SLOT" over "ABI_SLOT" (at least for this case, not > > sure about others I could be missing now...) > > The :* operator doesn't trigger any rebuilds though. Quoting the PMS > patch that you linked: > > * Indicates that any slot value is acceptable. In addition, for runtime > dependencies, indicates that the package will not break if the matched > package is uninstalled and replaced by a different matching package in a > different slot. I mean, use it in conjunction with ":=", one for rebuild and other to indicate any 2.x SLOT fits the "normal" RDEPEND (to not need to periodically update RDEPENDs or need to go back from :SLOT depends to old =category/package-version-* ways) Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue that arises with using only SLOTs for this) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 12:24 PM, Pacho Ramos wrote: > El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: >> On 06/07/2012 12:00 PM, Pacho Ramos wrote: >>> El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos wrote: >> I would prefer, as a workaround, allow reverse deps to RDEPEND on >> glib:2.* instead. That way it would cover more cases when more than >> two slots are available > > Well, per: > http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b > > looks like "*" usage for SLOTs would be allowed :), or I am > misinterpreting it? It's not a wildcard. >>> >>> But it looks like a valid usage for cases like glib vs. >>> dbus-glib/gobject-introspection I have exposed as example, and also >>> allows us to keep "SLOT" over "ABI_SLOT" (at least for this case, not >>> sure about others I could be missing now...) >> >> The :* operator doesn't trigger any rebuilds though. Quoting the PMS >> patch that you linked: >> >> * Indicates that any slot value is acceptable. In addition, for runtime >> dependencies, indicates that the package will not break if the matched >> package is uninstalled and replaced by a different matching package in a >> different slot. > > I mean, use it in conjunction with ":=", one for rebuild and other to > indicate any 2.x SLOT fits the "normal" RDEPEND (to not need to > periodically update RDEPENDs or need to go back from :SLOT depends to > old =category/package-version-* ways) > > Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue > that arises with using only SLOTs for this) What you're talking about here is more similar to ABI_SLOT operator deps than what was originally intended for SLOT operator deps. In other words, anyone who is opposed to ABI_SLOT operator deps is likely to also be opposed to your proposal. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, Jun 07, 2012 at 08:15:28PM +0100, Ciaran McCreesh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 07 Jun 2012 15:14:03 -0400 > Ian Stakenvicius wrote: > > How is the case of something like libpng going to be handled, where we > > only support one API (and so only one SLOT)? Either in the proposed > > ABI_SLOT thing or when using slot operators? > > Ideally, by you putting in the work and supporting more than one API, > since doing so vastly improves the user experience. > > Failing that, SLOT plus blockers. Then if it turns out that really > doesn't work (and it's not just developers being utterly lazy), either > ABI_SLOT or parts in a future EAPI. SLOT + blockers only works for API breakages; for instances where API is the same but the ABI has shifted (a lib function switching from taking a short switching to a long for example), the scheme doesn't work and rebuilding is what's required. Thing is, the API breakage bit we already have sorted; point of this whole discussion is dealing w/ the latter scenario, which slot + blockers *doesn't* address; not unless your proposal is the clusterfuck notion of modifying the ebuild providing the lib, and sticking a shite ton of blockers for every known consumer. That approach is wrong on multiple levels to say the least. > > For the slot-operator case, will every consumer of libpng be forced to > > change their dep to libpng:= to ensure they get rebuilt when libpng > > bumps from 1.5 to 1.6?? > > Every consumer of libpng that wants to improve from the current > situation, yes. Just going to point something out here; you've spent a lot of time stating "Someone else has to go sort these problems out"- problems that in many cases are decades old. You want to enforce this hard line, you do the work. Reminder: Ebuilds sole purpose are to make integrators jobs easier. Not to enforce the views of EAPI authors, but to enable people to get shit done. ABI_SLOT should *not* be used all over the place; it's basically a corner case variable that allows integrators to work around known cranky upstreams, or generally thorny ass problems. Aka, scenarios where the slotting solution doesn't fit. Unless ciaran's plan is to step up and fix all of these offending scenarios (and keep doing so), ABI_SLOT should be landed at the same time as SLOT operators. We already know it has uses, and when it *occurs*, it's painful to deal with it- specifically at the user level. Provide the PM the neccessary data, and it can lessen that pain. ~harring
[gentoo-dev] RFC: vcs-snapshot-r1.eclass -- a better eclass for VCS snapshots (and others)
Hello,
As it was pointed out, vcs-snapshot is unable to handle multiple
tarballs nicely. As fixing this would involve changing eclass API
(and they are packages which are known to break thanks to it), I'm
posting a new eclass for review. Of course, if the community insists,
I could just update the old eclass and fix the ebuilds broken that way.
The idea with the new eclass is to extract all supported archives
(which means .tar* at the point) into ${WORKDIR} subdirectories
matching their names. In other words, if you've got:
SRC_URI="http://foo/getbar -> ${P}.tar.bz2
http://foo/getbaz -> ${P}-data.tar.bz2"
You'd get the contents in ${WORKDIR}/${P} and ${WORKDIR}/${P}-data
respectively.
A few things to note:
1) the implemention just dumbly uses 'tar --strip-components'. If it
hits a tarball without a single top-level directory, scary things will
happen;
2) only tarballs are handled, other archives are just passed through
to unpack;
3) at some point the eclass could be extended to handle more formats.
So if you've got other archives in your SRC_URI, please make sure they
are named consistently with the parent dir, so that they would not
relocate when support for that particular format is added.
By the way, the credit for the overall idea goes to hasufell.
--
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: vcs-snapshot-r1.eclass
# @MAINTAINER:
# mgo...@gentoo.org
# @BLURB: support eclass for unpacking VCS snapshot tarballs
# @DESCRIPTION:
# This eclass provides a convenience src_unpack() which does unpack all
# the tarballs in SRC_URI to locations matching their (local) names,
# discarding the original parent directory.
#
# The typical use case are VCS snapshots, coming from github, bitbucket
# and similar services. They have hash appended to the directory name
# which makes extracting them a painful experience. But if you just use
# a SRC_URI arrow to rename it (which you're likely have to do anyway),
# vcs-snapshot will just extract it into a matching directory.
#
# Please note that this eclass handles only tarballs (.tar, .tar.gz,
# .tar.bz2 & .tar.xz). For any other file format (or suffix) it will
# fall back to regular unpack. Support for additional formats may be
# added at some point so please keep your SRC_URIs clean.
#
# @EXAMPLE:
#
# @CODE
# EAPI=4
# AUTOTOOLS_AUTORECONF=1
# inherit autotools-utils vcs-snapshot-r1
#
# SRC_URI="http://github.com/example/${PN}/tarball/v${PV} -> ${P}.tar.gz"
# @CODE
#
# and however the tarball was originally named, all files will appear
# in ${WORKDIR}/${P}.
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die "vcs-snapshot-r1.eclass API in EAPI ${EAPI} not yet established."
esac
EXPORT_FUNCTIONS src_unpack
vcs-snapshot-r1_src_unpack() {
local f
for f in ${A}
do
case "${f}" in
*.tar|*.tar.gz|*.tar.bz2|*.tar.xz)
local destdir=${WORKDIR}/${f%.tar*}
# XXX: check whether the directory structure
inside is
# fine? i.e. if the tarball has actually a
parent dir.
mkdir "${destdir}" || die
tar -C "${destdir}" -x --strip-components 1 \
-f "${DISTDIR}/${f}" || die
;;
*)
# fall back to the default method
unpack "${f}"
;;
esac
done
}
signature.asc
Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 11:04 AM, Ralph Sennhauser wrote: > On Thu, 07 Jun 2012 09:43:32 -0700 > Zac Medico wrote: > >> On 06/07/2012 01:24 AM, Brian Harring wrote: >>> I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing >>> in '06/'07); I'd however suggest ensuring there is some buy in from >>> devs on that one since that was the main argument against it in the >>> past. >> >> I can imagine that ABI_SLOT operator deps will be a lot more popular >> than SLOT operator deps, since ABI_SLOT operator deps will accommodate >> the common practice of allowing ABI changes within a particular SLOT. > > What for? So we won't ever get rid of revdep-rebuild resp. > @preserved-libs? Except for the ranged dep problem I don't see any > additional benefit but potential drawbacks. Please correct me where I'm > wrong. ABI_SLOT operator deps *do* allow us to get rid of revdep-rebuild, since they are usable in cases like the dbus-glib/glib:2 dependency, where SLOT operator deps are unmanageable. -- Thanks, Zac
