Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On Mon, 2008-10-13 at 19:59 +0200, Fabian Groffen wrote:
On 13-10-2008 15:27:10 +0100, Ciaran McCreesh wrote:
On Mon, 13 Oct 2008 06:16:01 +0100
Steve Long [EMAIL PROTECTED] wrote:
Unless someone can say what using PROPERTIES=prefix would break, I'd
go with that. It's a /classic/ usage of that variable, as it's simply
a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
support it. It'd be great to see the prefix branch finally merged so
we all get to play with it.
It would break. Prefix ebuilds won't work unless ED is set, and a non
PROPERTIES aware or non-prefix-property aware package manager won't set
ED. Unless prefix is reimplemented to require no package manager
changes for the install to / case, PROPERTIES is out.
Just to comment on this possibility; I see an option, given the
definition of ED and EROOT to do Prefix without them, by e.g. using
${D}${EPREFIX} instead of ${ED} as shorthand. When ${EPREFIX} would be
unset, this would result in simple ${D}, which is backwards
compatible. This is not all what is necessary, but a big deal of it.
Question here, however, is whether this is worth it. Personally, I
prefer the shorthands, as they give a lot of readability.
Could it also work to initialize them in profile.bashrc if they are
unset?
Something like
: ${EPREFIX=}
: ${ED=${D}}
: ${EROOT=${ROOT}}
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
Re: [gentoo-dev] RFC: fox.eclass update
--- gentoo-x86/eclass/fox.eclass 2008-10-12 14:31:36.0 +0200
+++ fox-proposed.eclass 2008-10-13 20:27:05.0 +0200
[...]
-inherit eutils libtool versionator
+inherit autotools eutils libtool versionator
You should probably be setting WANT_AUTO* before inheriting autotools.
[...]
+ if ( ! use doc ) [ -d ${D}/usr/share/doc/${PF}/html ] ; then
Get rid of the pointless subshell.
if use !doc ...
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] System packages in (R)DEPEND?
В Пнд, 13/10/2008 в 14:34 -0500, Jeremy Olexa пишет: On Sun, Oct 12, 2008 at 12:04 PM, Thomas Sachau [EMAIL PROTECTED] wrote: Should we depend on all system packages? Should we depend on some packages, because they could be removed? If yes, which ones? Or should we leave the system packages out completly? https://bugs.gentoo.org/show_bug.cgi?id=221311 Please provide reasons/justifications for the proposal of removing Our documentation, QA team insist that we should not depend on system packages and there are good reasons to do that. But still above bug clearly states different. Also if we consider perl and some other packages, they also could became target to be removed... But I'm not going to repeat discussion we already had recently: http://thread.gmane.org/gmane.linux.gentoo.devel/54035 So yes, there is ambiguity and the question is valid. But since we had discussion recently I don't see what else we can discuss now. -- Peter.
Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs
On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote: On 02:03 Tue 14 Oct , Jose Luis Rivero wrote: There are some others sceneries but are not so common as the one presented could be. Any decent solution for this case? There are only a few obvious ones, you'll have to pick which one you like best. Most of the other options basically duplicate these in some way or add more work to them for negligible gain: - Backport the ebuild from EAPI=2 to EAPI=0 EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is going to happen when we release new and more feature rich EAPIs), and changes usually come with bugs. The ebuild is committed directly to stable implies bugs in stable, which for me is a no-go. - Backport the security patch to the EAPI=0 ebuild Which sometimes is going to be impossible, require lot of work, and we fall into the risk of bad backported patches when non trivial backport patches are needed (which turns into buggy patches in the stable branch) - Stabilize portage quickly Most of the times this is not going to be possible. Seems to me that EAPI changes are not trivial to PMs and need some kind of decent testing period. Thanks. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Doc Gentoo/Alpha
Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs
On Tue, 14 Oct 2008 10:59:39 +0200 Jose Luis Rivero [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote: On 02:03 Tue 14 Oct , Jose Luis Rivero wrote: There are some others sceneries but are not so common as the one presented could be. Any decent solution for this case? There are only a few obvious ones, you'll have to pick which one you like best. Most of the other options basically duplicate these in some way or add more work to them for negligible gain: - Backport the ebuild from EAPI=2 to EAPI=0 EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is going to happen when we release new and more feature rich EAPIs), and changes usually come with bugs. The ebuild is committed directly to stable implies bugs in stable, which for me is a no-go. Assuming the ebuild changes between foo-1 and foo-2 are mainly due to the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many cases) you could just reuse the foo-1 ebuild for foo-3. If there are major differences between foo-1 and foo-2 not related to the EAPI change then the maintainer probably didn't want foo-2 to become stable anytime soon, so it's at least questionable if foo-3 should go straight to stable in the first place. And adding a new version directly to stable always comes with a risk, you can't eliminate that completely. It's all about risk assessment, and how much work you're willing to do or time you want to spend to minimize the risk. - Backport the security patch to the EAPI=0 ebuild Which sometimes is going to be impossible, require lot of work, and we fall into the risk of bad backported patches when non trivial backport patches are needed (which turns into buggy patches in the stable branch) And sometimes it's a very viable option when patches are provided by upstream. In the end at least one of the above solutions should work in almost every case. It might sometimes cause a bit more work than a bump that doesn't involve any EAPI changes, but that's life. If you have a real case where both suggested solutions aren't realistic I'd like to hear about it, otherwise I think we're wasting time making up solutions for a non-existant problem Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs
Marius Mauch kirjoitti: On Tue, 14 Oct 2008 10:59:39 +0200 Jose Luis Rivero [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote: On 02:03 Tue 14 Oct , Jose Luis Rivero wrote: There are some others sceneries but are not so common as the one presented could be. Any decent solution for this case? There are only a few obvious ones, you'll have to pick which one you like best. Most of the other options basically duplicate these in some way or add more work to them for negligible gain: - Backport the ebuild from EAPI=2 to EAPI=0 EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is going to happen when we release new and more feature rich EAPIs), and changes usually come with bugs. The ebuild is committed directly to stable implies bugs in stable, which for me is a no-go. Assuming the ebuild changes between foo-1 and foo-2 are mainly due to the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many cases) you could just reuse the foo-1 ebuild for foo-3. If there are major differences between foo-1 and foo-2 not related to the EAPI change then the maintainer probably didn't want foo-2 to become stable anytime soon, so it's at least questionable if foo-3 should go straight to stable in the first place. And adding a new version directly to stable always comes with a risk, you can't eliminate that completely. It's all about risk assessment, and how much work you're willing to do or time you want to spend to minimize the risk. There's no need to commit straight to stable. Just make two different new revisions for each EAPI. Then the arch teams can test it like usual. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs
On Tue, Oct 14, 2008 at 3:34 PM, Petteri Räty [EMAIL PROTECTED] wrote: Marius Mauch kirjoitti: On Tue, 14 Oct 2008 10:59:39 +0200 Jose Luis Rivero [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote: On 02:03 Tue 14 Oct , Jose Luis Rivero wrote: There are some others sceneries but are not so common as the one presented could be. Any decent solution for this case? There are only a few obvious ones, you'll have to pick which one you like best. Most of the other options basically duplicate these in some way or add more work to them for negligible gain: - Backport the ebuild from EAPI=2 to EAPI=0 EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is going to happen when we release new and more feature rich EAPIs), and changes usually come with bugs. The ebuild is committed directly to stable implies bugs in stable, which for me is a no-go. Assuming the ebuild changes between foo-1 and foo-2 are mainly due to the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many cases) you could just reuse the foo-1 ebuild for foo-3. If there are major differences between foo-1 and foo-2 not related to the EAPI change then the maintainer probably didn't want foo-2 to become stable anytime soon, so it's at least questionable if foo-3 should go straight to stable in the first place. And adding a new version directly to stable always comes with a risk, you can't eliminate that completely. It's all about risk assessment, and how much work you're willing to do or time you want to spend to minimize the risk. There's no need to commit straight to stable. Just make two different new revisions for each EAPI. Then the arch teams can test it like usual. Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are there multiple versions of the same package' questions and complexities. [1] http://www.gentoo.org/proj/en/glep/glep-0055.html Regards, Petteri
