[gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[Michał Górny]

One could set S to work on a subtree of the tarball rather than
the whole tarball. Considering that, it's probably better to use
${WORKDIR}/${P} rather than ${S}.

Fixes: https://bugs.gentoo.org/show_bug.cgi?id=419479
---
 gx86/eclass/vcs-snapshot.eclass |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gx86/eclass/vcs-snapshot.eclass b/gx86/eclass/vcs-snapshot.eclass
index 6748360..23cd696 100644
--- a/gx86/eclass/vcs-snapshot.eclass
+++ b/gx86/eclass/vcs-snapshot.eclass
@@ -9,7 +9,8 @@
 # @DESCRIPTION:
 # This eclass provides a convenience src_unpack() which does support
 # working with snapshots generated by various VCS-es. It unpacks those
-# to ${S} rather than the original directory containing commit id.
+# to ${WORKDIR}/${P} rather than the original directory containing
+# commit id.
 #
 # Note that this eclass handles only unpacking. You need to specify
 # SRC_URI yourself, and call any autoreconfiguration as necessary.
@@ -41,5 +42,5 @@ vcs-snapshot_src_unpack() {
 
 	# github, bitbucket: username-projectname-hash
 	# gitweb: projectname-tagname-hash
-	mv *-*-[0-9a-f]*[0-9a-f]/ "${S}" || die
+	mv *-*-[0-9a-f]*[0-9a-f]/ "${WORKDIR}"/${P} || die
 }
-- 
1.7.10.2

Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[hasufell]

[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/04/2012 11:59 AM, Michał Górny wrote:
> One could set S to work on a subtree of the tarball rather than the
> whole tarball. Considering that, it's probably better to use 
> ${WORKDIR}/${P} rather than ${S}.
> 
> Fixes: https://bugs.gentoo.org/show_bug.cgi?id=419479 --- 
> gx86/eclass/vcs-snapshot.eclass |    5 +++-- 1 file changed, 3
> insertions(+), 2 deletions(-)
> 
> diff --git a/gx86/eclass/vcs-snapshot.eclass
> b/gx86/eclass/vcs-snapshot.eclass index 6748360..23cd696 100644 ---
> a/gx86/eclass/vcs-snapshot.eclass +++
> b/gx86/eclass/vcs-snapshot.eclass @@ -9,7 +9,8 @@ # @DESCRIPTION: #
> This eclass provides a convenience src_unpack() which does support 
> # working with snapshots generated by various VCS-es. It unpacks
> those -# to ${S} rather than the original directory containing
> commit id. +# to ${WORKDIR}/${P} rather than the original directory
> containing +# commit id. # # Note that this eclass handles only
> unpacking. You need to specify # SRC_URI yourself, and call any
> autoreconfiguration as necessary. @@ -41,5 +42,5 @@
> vcs-snapshot_src_unpack() {
> 
> # github, bitbucket: username-projectname-hash # gitweb:
> projectname-tagname-hash -	mv *-*-[0-9a-f]*[0-9a-f]/ "${S}" || die 
> +	mv *-*-[0-9a-f]*[0-9a-f]/ "${WORKDIR}"/${P} || die }

Currently that eclass does not support multiple snapshot sources/tarballs.

I would suggest to fix that. My proposal currently breaks 6 ebuilds
which do not follow the newly described standard.

This way you could merge data and source snapshots from vcs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPzMQSAAoJEFpvPKfnPDWzJdMH/AuhgbDeVdnJViP+zZNjsq4B
C2FlaPCpl3HHTrMi7HhbFmbOnZeLA3VLaffdvaPvZU0O1RxhOQPNfp4t8/E2iuHF
q9vVwQFQe19izFa7EgapD2EOUVUeaNMGoX0K2qRgtfLeBwnLWsnagMYZkV2+5skA
84vnyRYtaDEx6Z+M0UipwFnubrgmItbvX7F3XZ3omCdlSjXaRDO0sc2hqMFjeZ5P
ESGfbWxFX59ztmxBni0iSJE3NdSiYr1mjuW6eFZazIq9T6cinByXfMJgbdz7N14e
8HaSxMTc6PVWUTVbmpj3POWnZ+KCHbFze39rO5HzY4ZPMIL4xTxXAppg2FnyhF4=
=KUJi
-----END PGP SIGNATURE-----

[-- Attachment #2: vcs-snapshot.eclass.diff --]
[-- Type: text/x-patch, Size: 1874 bytes --]

--- vcs-snapshot.eclass.old	2012-06-04 16:10:25.000000000 +0200
+++ vcs-snapshot.eclass	2012-06-04 16:11:16.000000000 +0200
@@ -8,8 +8,10 @@
 # @BLURB: support eclass for VCS (github, bitbucket, gitweb) snapshots
 # @DESCRIPTION:
 # This eclass provides a convenience src_unpack() which does support
-# working with snapshots generated by various VCS-es. It unpacks those
-# to ${S} rather than the original directory containing commit id.
+# working with snapshots generated by various VCS-es. It unpacks all tarballs
+# and zipballs according to their name into ${WORKDIR}/${name}
+# rather than the original directory containing commit id.
+# See example below.
 #
 # Note that this eclass handles only unpacking. You need to specify
 # SRC_URI yourself, and call any autoreconfiguration as necessary.
@@ -26,6 +28,10 @@
 # inherit autotools-utils vcs-snapshot
 #
 # SRC_URI="http://github.com/example/${PN}/tarball/v${PV} -> ${P}.tar.gz"
+# 
+# # line above unpacks into: ${WORKDIR}/${P}
+# # SRC_URI="http://github.com/example/${PN}/tarball/v${PV} -> ${P}-src.tar.gz"
+# # would unpack into: ${WORKDIR}/${P}-src
 # @CODE
 
 case ${EAPI:-0} in
@@ -37,9 +43,21 @@
 EXPORT_FUNCTIONS src_unpack
 
 vcs-snapshot_src_unpack() {
-	default
-
 	# github, bitbucket: username-projectname-hash
 	# gitweb: projectname-tagname-hash
-	mv *-*-[0-9a-f]*[0-9a-f]/ "${S}" || die
+	local i
+	local _tmpdir=${T}/_tmp
+	mkdir "${_tmpdir}" || die
+	pushd "${_tmpdir}" > /dev/null || die
+	for i in ${A} ; do
+		unpack ${i}
+		case ${i} in
+			*.tar.gz) mv "${_tmpdir}"/*/ "${WORKDIR}"/${i%.tar.gz} || die ;;
+			*.tar.xz) mv "${_tmpdir}"/*/ "${WORKDIR}"/${i%.tar.xz} || die ;;
+			*.tar.bz2) mv "${_tmpdir}"/*/ "${WORKDIR}"/${i%.tar.bz2} || die ;;
+			*.zip) mv "${_tmpdir}"/*/ "${WORKDIR}"/${i%.zip} || die ;;
+			*) mv "${_tmpdir}"/* "${WORKDIR}"/ ;;
+		esac
+	done
+	popd > /dev/null
 }

[-- Attachment #3: vcs-snapshot.eclass --]
[-- Type: text/plain, Size: 2151 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/vcs-snapshot.eclass,v 1.2 2012/03/19 08:52:49 mgorny Exp $

# @ECLASS: vcs-snapshot.eclass
# @MAINTAINER:
# mgorny@gentoo.org
# @BLURB: support eclass for VCS (github, bitbucket, gitweb) snapshots
# @DESCRIPTION:
# This eclass provides a convenience src_unpack() which does support
# working with snapshots generated by various VCS-es. It unpacks all tarballs
# and zipballs according to their name into ${WORKDIR}/${name}
# rather than the original directory containing commit id.
# See example below.
#
# Note that this eclass handles only unpacking. You need to specify
# SRC_URI yourself, and call any autoreconfiguration as necessary.
# The example does that using autotools-utils eclass.
#
# Right now, the eclass was tested with github, bitbucket and gitweb
# snapshots. Feel free to report snapshotting services which aren't
# working.
# @EXAMPLE:
#
# @CODE
# EAPI=4
# AUTOTOOLS_AUTORECONF=1
# inherit autotools-utils vcs-snapshot
#
# SRC_URI="http://github.com/example/${PN}/tarball/v${PV} -> ${P}.tar.gz"
# 
# # line above unpacks into: ${WORKDIR}/${P}
# # SRC_URI="http://github.com/example/${PN}/tarball/v${PV} -> ${P}-src.tar.gz"
# # would unpack into: ${WORKDIR}/${P}-src
# @CODE

case ${EAPI:-0} in
	0|1) die "EAPI ${EAPI} unsupported.";; # default(), SRC_URI arrows
	2|3|4) ;;
	*) die "vcs-snapshot.eclass API in EAPI ${EAPI} not yet established."
esac

EXPORT_FUNCTIONS src_unpack

vcs-snapshot_src_unpack() {
	# github, bitbucket: username-projectname-hash
	# gitweb: projectname-tagname-hash
	local i
	local _tmpdir=${T}/_tmp
	mkdir "${_tmpdir}" || die
	pushd "${_tmpdir}" > /dev/null || die
	for i in ${A} ; do
		unpack ${i}
		case ${i} in
			*.tar.gz) mv "${_tmpdir}"/*/ "${WORKDIR}"/${i%.tar.gz} || die ;;
			*.tar.xz) mv "${_tmpdir}"/*/ "${WORKDIR}"/${i%.tar.xz} || die ;;
			*.tar.bz2) mv "${_tmpdir}"/*/ "${WORKDIR}"/${i%.tar.bz2} || die ;;
			*.zip) mv "${_tmpdir}"/*/ "${WORKDIR}"/${i%.zip} || die ;;
			*) mv "${_tmpdir}"/* "${WORKDIR}"/ ;;
		esac
	done
	popd > /dev/null
}

Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

On Mon, 04 Jun 2012 16:20:02 +0200
hasufell <hasufell@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/04/2012 11:59 AM, Michał Górny wrote:
> > One could set S to work on a subtree of the tarball rather than the
> > whole tarball. Considering that, it's probably better to use 
> > ${WORKDIR}/${P} rather than ${S}.
> > 
> > Fixes: https://bugs.gentoo.org/show_bug.cgi?id=419479 --- 
> > gx86/eclass/vcs-snapshot.eclass |    5 +++-- 1 file changed, 3
> > insertions(+), 2 deletions(-)
> > 
> > diff --git a/gx86/eclass/vcs-snapshot.eclass
> > b/gx86/eclass/vcs-snapshot.eclass index 6748360..23cd696 100644 ---
> > a/gx86/eclass/vcs-snapshot.eclass +++
> > b/gx86/eclass/vcs-snapshot.eclass @@ -9,7 +9,8 @@ # @DESCRIPTION: #
> > This eclass provides a convenience src_unpack() which does support 
> > # working with snapshots generated by various VCS-es. It unpacks
> > those -# to ${S} rather than the original directory containing
> > commit id. +# to ${WORKDIR}/${P} rather than the original directory
> > containing +# commit id. # # Note that this eclass handles only
> > unpacking. You need to specify # SRC_URI yourself, and call any
> > autoreconfiguration as necessary. @@ -41,5 +42,5 @@
> > vcs-snapshot_src_unpack() {
> > 
> > # github, bitbucket: username-projectname-hash # gitweb:
> > projectname-tagname-hash -	mv *-*-[0-9a-f]*[0-9a-f]/ "${S}"
> > || die 
> > +	mv *-*-[0-9a-f]*[0-9a-f]/ "${WORKDIR}"/${P} || die }
> 
> Currently that eclass does not support multiple snapshot
> sources/tarballs.

Use case?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/04/2012 05:50 PM, Michał Górny wrote:
> On Mon, 04 Jun 2012 16:20:02 +0200 hasufell <hasufell@gentoo.org>
> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 06/04/2012 11:59 AM, Michał Górny wrote:
>>> One could set S to work on a subtree of the tarball rather than
>>> the whole tarball. Considering that, it's probably better to
>>> use ${WORKDIR}/${P} rather than ${S}.
>>> 
>>> Fixes: https://bugs.gentoo.org/show_bug.cgi?id=419479 --- 
>>> gx86/eclass/vcs-snapshot.eclass |    5 +++-- 1 file changed, 3 
>>> insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/gx86/eclass/vcs-snapshot.eclass 
>>> b/gx86/eclass/vcs-snapshot.eclass index 6748360..23cd696 100644
>>> --- a/gx86/eclass/vcs-snapshot.eclass +++ 
>>> b/gx86/eclass/vcs-snapshot.eclass @@ -9,7 +9,8 @@ #
>>> @DESCRIPTION: # This eclass provides a convenience src_unpack()
>>> which does support # working with snapshots generated by
>>> various VCS-es. It unpacks those -# to ${S} rather than the
>>> original directory containing commit id. +# to ${WORKDIR}/${P}
>>> rather than the original directory containing +# commit id. # #
>>> Note that this eclass handles only unpacking. You need to
>>> specify # SRC_URI yourself, and call any autoreconfiguration as
>>> necessary. @@ -41,5 +42,5 @@ vcs-snapshot_src_unpack() {
>>> 
>>> # github, bitbucket: username-projectname-hash # gitweb: 
>>> projectname-tagname-hash -	mv *-*-[0-9a-f]*[0-9a-f]/ "${S}" ||
>>> die +	mv *-*-[0-9a-f]*[0-9a-f]/ "${WORKDIR}"/${P} || die }
>> 
>> Currently that eclass does not support multiple snapshot 
>> sources/tarballs.
> 
> Use case?
> 

ANY case where I need more than one tarball/source. There are just not
many because this eclass is widely unknown.

But minetest in sunrise for example which has two different repos, one
for the engine, one for the data. It's currently split in two, but I
guess I will merge those soon.

Lately there was an ebuild proposal in sunrise too which had that
issue, see here https://gist.github.com/2829184

It would also enable me to use gtk-youtube-viewer and youtube-viewer
in one ebuild with vcs-snapshot eclass while adding a gtk useflag
(currently split too).
Otherwise I will have to fix it on my own again.

I am pretty sure it will get more in the future when people start to
use this eclass or it will just prevent them from using it.

I find the logic very clear:

SRC="https://my/github/shit -> ${P}.tar.gz"
results in ${WORKDIR}/${P}
and
SRC="https://my/github/shit -> ${P}-src.tar.gz"
results in ${WORKDIR}/${P}-src
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPzQvIAAoJEFpvPKfnPDWzOikH/0R35jeWyWj1j7RNxQ9Rbpt6
JPSBmNx2ZOdFDF8jIqbOERwFwSe87mLitOrZafCxNL4eNZmhP4lXTcVny574CxuS
DE6k5n7k265eYzZm4A/1CjdKp4ptTzpGVil4/iVObFaz3B7tS5PCvqzySWc/ZO/7
040x2d4g94nqkcMM130ua970pbgO7MWZsVsBH3mnLE4AGCZY4vtRlH9dMOHbcAgG
46Vuu9/m4BfGadfGqNVTZz7KbxDBt5h3vOHZZe6JEf3smMr9GiK/gcIc4l97faN7
B601V8kIBWQhPENgeh+SZsMpx24E8DIMvLA7ltMLF8/WLULQBxzW3xR4/CxoNOk=
=aaKu
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

On Mon, 04 Jun 2012 21:26:00 +0200
hasufell <hasufell@gentoo.org> wrote:

> But minetest in sunrise for example which has two different repos, one
> for the engine, one for the data. It's currently split in two, but I
> guess I will merge those soon.

Why? Is there a good reason to merge two repos into one ebuild? Does
upstream guarantee that the releases will always be synced? Does it
benefit users?

> Lately there was an ebuild proposal in sunrise too which had that
> issue, see here https://gist.github.com/2829184

That's a more likely case. But still such a change would involve
changing an established API heavily which I really dislike.

> It would also enable me to use gtk-youtube-viewer and youtube-viewer
> in one ebuild with vcs-snapshot eclass while adding a gtk useflag
> (currently split too).
> Otherwise I will have to fix it on my own again.

Once again: does it benefit user? Or just does it imply that starting
or stopping to use gtk part requires user to rebuild the whole thing?

> I find the logic very clear:
> 
> SRC="https://my/github/shit -> ${P}.tar.gz"
> results in ${WORKDIR}/${P}
> and
> SRC="https://my/github/shit -> ${P}-src.tar.gz"
> results in ${WORKDIR}/${P}-src

I really don't mind the logic. I'm just aware that it is a little late
to introduce such a destructive change, especially that you yourself
mentioned that it will break existing ebuilds.

I will be happy to implement it if you can get more approval for that
change. Or else we should consider jumping with the eclass to -r1 while
it isn't widespread too much.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/04/2012 10:06 PM, Michał Górny wrote:
> On Mon, 04 Jun 2012 21:26:00 +0200 hasufell <hasufell@gentoo.org>
> wrote:
> 
>> But minetest in sunrise for example which has two different
>> repos, one for the engine, one for the data. It's currently split
>> in two, but I guess I will merge those soon.
> 
> Why? Is there a good reason to merge two repos into one ebuild?
> Does upstream guarantee that the releases will always be synced?
> Does it benefit users?

In this case yes. They are released with the exact same tags as you
can see in those ebuilds.

> 
>> It would also enable me to use gtk-youtube-viewer and
>> youtube-viewer in one ebuild with vcs-snapshot eclass while
>> adding a gtk useflag (currently split too). Otherwise I will have
>> to fix it on my own again.
> 
> Once again: does it benefit user? Or just does it imply that
> starting or stopping to use gtk part requires user to rebuild the
> whole thing?

Eclasses do not benefit any user. They benefit developers. I would
simply do similar stuff on my own in the ebuild instead of using
vcs-snapshot eclass then.

> 
>> I find the logic very clear:
>> 
>> SRC="https://my/github/shit -> ${P}.tar.gz" results in
>> ${WORKDIR}/${P} and SRC="https://my/github/shit ->
>> ${P}-src.tar.gz" results in ${WORKDIR}/${P}-src
> 
> I really don't mind the logic. I'm just aware that it is a little
> late to introduce such a destructive change, especially that you
> yourself mentioned that it will break existing ebuilds.

So? We fix it.

> 
> I will be happy to implement it if you can get more approval for
> that change. Or else we should consider jumping with the eclass to
> -r1 while it isn't widespread too much.
> 

I don't see the point in bumping it, because it's not widespread.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPzR7lAAoJEFpvPKfnPDWz5W8H/0Je1mE/Vo7X+46TpuZZyi/3
RJaJMYETeQbbhPM6ACIXtHk629fGCz9Oda7J0YG4LMCYTbxU5MNElZSjbV4aThYD
MkSoQlSw/RIBuSEaffWRkAtbmNovHzd+nUyK8cHJTYXffi4CmClPXPPTqGAaRbC/
yJf6JBEfMLK/6ps10eMwf7D/m5ZJUYIPJ1m7DmlUqjpr8R8v2bVbjqB//M9ig7KO
yl/W5qzlBa2UAw/Gjgi0ITdDKs5sem7J8+PbVZKED5K0sD10YxZKMImCymJSlFkR
gzqZi99qdAs8uhZ1K6h8ozkBLglxkT54IZ8Kn3LWwiQ0/I2xRNgX8Ugt1EQnrQM=
=X+fU
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]

On Mon, 04 Jun 2012 22:47:33 +0200
hasufell <hasufell@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/04/2012 10:06 PM, Michał Górny wrote:
> > On Mon, 04 Jun 2012 21:26:00 +0200 hasufell <hasufell@gentoo.org>
> > wrote:
> > 
> >> But minetest in sunrise for example which has two different
> >> repos, one for the engine, one for the data. It's currently split
> >> in two, but I guess I will merge those soon.
> > 
> > Why? Is there a good reason to merge two repos into one ebuild?
> > Does upstream guarantee that the releases will always be synced?
> > Does it benefit users?
> 
> In this case yes. They are released with the exact same tags as you
> can see in those ebuilds.

But could there be a case where fixing a build in the engine wouldn't
require data being rereleased? Or having the tag pointing to the same
commit it was pointing to previously?

If upstream splits a package, and supports building/installing the two
parts separately, we should do that as well.

> >> It would also enable me to use gtk-youtube-viewer and
> >> youtube-viewer in one ebuild with vcs-snapshot eclass while
> >> adding a gtk useflag (currently split too). Otherwise I will have
> >> to fix it on my own again.
> > 
> > Once again: does it benefit user? Or just does it imply that
> > starting or stopping to use gtk part requires user to rebuild the
> > whole thing?
> 
> Eclasses do not benefit any user. They benefit developers. I would
> simply do similar stuff on my own in the ebuild instead of using
> vcs-snapshot eclass then.

Does splitting the package benefit user? Gentoo has a long history of
overusing USE flags out of laziness. If upstream explicitly allows
building GTK+ part separately of core, we shouldn't merge that. We
should rather be grateful they don't force us to end up like Fedora,
splitting build tree into smaller packages.

> > I really don't mind the logic. I'm just aware that it is a little
> > late to introduce such a destructive change, especially that you
> > yourself mentioned that it will break existing ebuilds.
> 
> So? We fix it.

As I see the purpose of vcs-snapshot, it is more likely to be used in
various overlays than in the gx86 tree. I don't believe you are able to
fix *all* the occurrences.

And while we're at it, changing eclass APIs doesn't benefit users nor
developers. It can cause breakages which will hurt users, and forces
developers to do more work when they don't have time to.

> > I will be happy to implement it if you can get more approval for
> > that change. Or else we should consider jumping with the eclass to
> > -r1 while it isn't widespread too much.
> 
> I don't see the point in bumping it, because it's not widespread.

There are still more packages that it breaks than those which it would
actually benefit. But I like the idea of using filename for the
location. Could you look up PMS for me to see if it's guaranteed that
it will be preserved in $A?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 

> But could there be a case where fixing a build in the engine
> wouldn't require data being rereleased? Or having the tag pointing
> to the same commit it was pointing to previously?
> 
> If upstream splits a package, and supports building/installing the
> two parts separately, we should do that as well.

No. That is convenience for the minetest developer to have those
split. There is not much sense to have it split unless you don't want
to use the game and it adds further maintenance time for me.

It is also crucial to have the same version for both repos, cause
mixing engine and game-versions may lead to unexpected behavior. But I
don't understand how that discussion is related to this topic.

> 
> Does splitting the package benefit user? Gentoo has a long history
> of overusing USE flags out of laziness. If upstream explicitly
> allows building GTK+ part separately of core, we shouldn't merge
> that. We should rather be grateful they don't force us to end up
> like Fedora, splitting build tree into smaller packages.

Please have a look at those packages. It makes perfectly sense to
introduce a gtk useflag since they use almost the same perl
core-script, but it is not necessary.
This way I could conditionally install one version, since upstream
syncs this core-script between both variants.

> 
> As I see the purpose of vcs-snapshot, it is more likely to be used
> in various overlays than in the gx86 tree. I don't believe you are
> able to fix *all* the occurrences.

Alright, that may be true. I will have a look if it's possible to
enhance this without causing breakage for existing packages.

We may as well have this discussion later. As for your current
suggestion you have my ++
However the description stuff inside the eclass might need adjustment too.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPzfrbAAoJEFpvPKfnPDWzgAQH/1PdtK2RVRy8M43hW/s2v+wh
hRT3FZdEyFYmjMcOyNbzWlu0Y4DnFfbJIYbVWKrr892NQB4o+o4kaEpHmB0wX/gI
Igu1ojGkntpfH9NFFXvZDTSwcCLV6ZAtnfq/CAfl5Y100Xdnz64D3nhvse/kXUFH
6KYwUX7llsGGKFT3BU/w8i+PXecHDKNrqY48H3XnzTYxk92D6jMkXcSk6PXqVYJQ
C1Ug5mjWSBd4ZIPl3CIxxkVXQMFYOgRmM38/vztMNaAt7ypXVJL1sdmR4VHr7k2S
WnBtw+eKwTuYJb/M/vHfANhudIOtNOfvCQPZA9nmU5qKpgJ2/iyZAYnhN/WfAd4=
=965z
-----END PGP SIGNATURE-----