Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: hasufell <hasufell@g.o>
Subject: Re: [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
Date: Tue, 05 Jun 2012 14:26:03 +0200
-----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-----


References:
[PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
-- Michał Górny
Re: [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
-- hasufell
Re: [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
-- Michał Górny
Re: [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
-- hasufell
Re: [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
-- Michał Górny
Re: [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
-- hasufell
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
Next by thread:
[java-utils-2.eclass] - removal of java-pkg_ensure-test and java-pkg_ensure-gcj
Previous by date:
Re: Git braindump: 2 of N: developer interaction (merge co-ordinators)
Next by date:
Re: [gentoo-portage-dev] About forcing rebuilds of other packages issue


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.