[gentoo-dev] Moving functionality out of portage and into the tree

[gentoo-dev] Moving functionality out of portage and into the tree

[Brian Harring]

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

Note: pardon the dual post, resending this since I managed to leave a
subject off of... any discussion regarding this, please start the thread
from this message... sorry about that :-)

Currently portage bundles all do* and new* scripts that ebuilds use with
each release.  In other words, the current breakage w/ dohtml -R not
handling files w/ spaces correctly is tied to a portage version
(<=.51_pre13).  Prior releases of portage will remain broke,
since the fix is tied to a portage release.

To head off the 'they should upgrade', yes, having a current portage is
important- that doesn't mean we can't split these files out so that they
*aren't* tied to a release.

Gentoo's pkg system is basically composed of two things; portage, the
executor of ebuild instructions, and the tree, the data for
compilation/installation of src.  Currently portage is basically
providing a collection of scripts/functions that are strictly used by
the ebuilds, basically a library of functions/scripts- basically 'data'
in the exec portion.

This 'library' should be placed into the tree, since portage isn't aware
of the scripts/functions even existing for the most part.  The do* and
new* scripts are specific to the customs we have for our tree, not
portage.

The scripts are kind of a no brainer for moving- what I'm also
proposing, is the creation of an ebuild-base eclass that is
automatically inherited, and lives in the tree.

Same thing, moving functions out of portage that are specific to our
tree, into the tree.

Fex: the amd64 crew is after being able to overload econf so that they
can specify where the 64bit libs should live; as it stands, they're
stuck until it's in a portage release.  If econf lived in the
ebuild-base class, this change could be flipped on regardless of the
users portage version.

The embedded crew are after something similar- see bug #55476, basically
need an addition to econf to do tweaks to configure scripts; as it
stands, they must wait for it a release.

The point of all of this is that these functions/scripts *aren't*
specific to portage the package, they're specific to our tree,
specifically the tree *at that moment*  I'd assume when it was decided
we would have these functions available for our ebuilds, they wound up
in the portage src for lack of a better place, which I view as the wrong
location.

Ebuild-base.eclass would hold econf, emake, ins*, and a few other
functions.

Assuming people have read this far, and agree, and this is actually
undertaken, the scripts/ebuild-base class should be controlled by a
herd- those who know the tree in and out would be best for the herd.
Basically, grab those who already are already doing serious QA of the
ebuilds in the tree.

As for actually doing these moves, it's pretty straightforward. 
Transferring the scripts out of portage pretty much consists of a PATH
addition in a portage release, for auto-inheriting ebuild-base.eclass,
addition of another src statement.  About it.

So... thoughts?
~brian

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Hasan Khalil]

Amen. Having to wait for a portage upgrade halts development for too 
long, particularly with the Gentoo for Mac OS X project (as well as the 
BSD project), both of which will need small changes to do* scripts, etc 
(dolib, anyone?).

	-Hasan

Brian Harring wrote:

> Note: pardon the dual post, resending this since I managed to leave a
> subject off of... any discussion regarding this, please start the thread
> from this message... sorry about that :-)
> 
> Currently portage bundles all do* and new* scripts that ebuilds use with
> each release.  In other words, the current breakage w/ dohtml -R not
> handling files w/ spaces correctly is tied to a portage version
> (<=.51_pre13).  Prior releases of portage will remain broke,
> since the fix is tied to a portage release.
> 
> To head off the 'they should upgrade', yes, having a current portage is
> important- that doesn't mean we can't split these files out so that they
> *aren't* tied to a release.
> 
> Gentoo's pkg system is basically composed of two things; portage, the
> executor of ebuild instructions, and the tree, the data for
> compilation/installation of src.  Currently portage is basically
> providing a collection of scripts/functions that are strictly used by
> the ebuilds, basically a library of functions/scripts- basically 'data'
> in the exec portion.
> 
> This 'library' should be placed into the tree, since portage isn't aware
> of the scripts/functions even existing for the most part.  The do* and
> new* scripts are specific to the customs we have for our tree, not
> portage.
> 
> The scripts are kind of a no brainer for moving- what I'm also
> proposing, is the creation of an ebuild-base eclass that is
> automatically inherited, and lives in the tree.
> 
> Same thing, moving functions out of portage that are specific to our
> tree, into the tree.
> 
> Fex: the amd64 crew is after being able to overload econf so that they
> can specify where the 64bit libs should live; as it stands, they're
> stuck until it's in a portage release.  If econf lived in the
> ebuild-base class, this change could be flipped on regardless of the
> users portage version.
> 
> The embedded crew are after something similar- see bug #55476, basically
> need an addition to econf to do tweaks to configure scripts; as it
> stands, they must wait for it a release.
> 
> The point of all of this is that these functions/scripts *aren't*
> specific to portage the package, they're specific to our tree,
> specifically the tree *at that moment*  I'd assume when it was decided
> we would have these functions available for our ebuilds, they wound up
> in the portage src for lack of a better place, which I view as the wrong
> location.
> 
> Ebuild-base.eclass would hold econf, emake, ins*, and a few other
> functions.
> 
> Assuming people have read this far, and agree, and this is actually
> undertaken, the scripts/ebuild-base class should be controlled by a
> herd- those who know the tree in and out would be best for the herd.
> Basically, grab those who already are already doing serious QA of the
> ebuilds in the tree.
> 
> As for actually doing these moves, it's pretty straightforward. 
> Transferring the scripts out of portage pretty much consists of a PATH
> addition in a portage release, for auto-inheriting ebuild-base.eclass,
> addition of another src statement.  About it.
> 
> So... thoughts?
> ~brian

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Mike Frysinger]

On Thursday 29 July 2004 05:36 am, Brian Harring wrote:
> So... thoughts?

this would allow us to move things like epatch and flag-o-matic out of 
eutils.eclass ...
my biggest problems with it being in portage are exactly what you mentioned:
(1) portage releases take a while
(2) fixes would have to be filed along with all the other bugs
(3) it just wouldnt happen :)

so toss my support with this :)
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Travis Tilley]

you have my --overwhelming-- support.


On Thursday 29 July 2004 05:36 am, Brian Harring wrote:
> The scripts are kind of a no brainer for moving- what I'm also
> proposing, is the creation of an ebuild-base eclass that is
> automatically inherited, and lives in the tree.

certainly better than my idea of cramming econf into eutils ^^;

> As for actually doing these moves, it's pretty straightforward.
> Transferring the scripts out of portage pretty much consists of a PATH
> addition in a portage release, for auto-inheriting ebuild-base.eclass,
> addition of another src statement.  About it.
>
> So... thoughts?

any idea when we might see this ability in a portage release?

-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Marius Mauch]

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

On 07/29/04  Travis Tilley wrote:

> any idea when we might see this ability in a portage release?

I'd say .52_preX or whatever post .51 will be called (assuming all
involved persons want it to happen).

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Cory Visi]

Theory aside, it really sounds like your two examples and everyone else's 
follow-ups have do to with the QA time on portage releases. The real 
problem is not that these utilities are part of portage releases, but that 
portage releases take too long to come out.

Is moving them into the portage tree so every developer can have at it the 
right solution? Will QA on these "base" utilities be neglected? How can we 
assure the same type of care with these utilities is taken as with portage 
releases?

I'm not against this move, I just want to discuss these issues.

Thanks,
Cory

On Thu, Jul 29, 2004 at 04:36:35AM -0500, Brian Harring wrote:
> Note: pardon the dual post, resending this since I managed to leave a
> subject off of... any discussion regarding this, please start the thread
> from this message... sorry about that :-)
> 
> Currently portage bundles all do* and new* scripts that ebuilds use with
> each release.  In other words, the current breakage w/ dohtml -R not
> handling files w/ spaces correctly is tied to a portage version
> (<=.51_pre13).  Prior releases of portage will remain broke,
> since the fix is tied to a portage release.
> 
> To head off the 'they should upgrade', yes, having a current portage is
> important- that doesn't mean we can't split these files out so that they
> *aren't* tied to a release.
> 
> Gentoo's pkg system is basically composed of two things; portage, the
> executor of ebuild instructions, and the tree, the data for
> compilation/installation of src.  Currently portage is basically
> providing a collection of scripts/functions that are strictly used by
> the ebuilds, basically a library of functions/scripts- basically 'data'
> in the exec portion.
> 
> This 'library' should be placed into the tree, since portage isn't aware
> of the scripts/functions even existing for the most part.  The do* and
> new* scripts are specific to the customs we have for our tree, not
> portage.
> 
> The scripts are kind of a no brainer for moving- what I'm also
> proposing, is the creation of an ebuild-base eclass that is
> automatically inherited, and lives in the tree.
> 
> Same thing, moving functions out of portage that are specific to our
> tree, into the tree.
> 
> Fex: the amd64 crew is after being able to overload econf so that they
> can specify where the 64bit libs should live; as it stands, they're
> stuck until it's in a portage release.  If econf lived in the
> ebuild-base class, this change could be flipped on regardless of the
> users portage version.
> 
> The embedded crew are after something similar- see bug #55476, basically
> need an addition to econf to do tweaks to configure scripts; as it
> stands, they must wait for it a release.
> 
> The point of all of this is that these functions/scripts *aren't*
> specific to portage the package, they're specific to our tree,
> specifically the tree *at that moment*  I'd assume when it was decided
> we would have these functions available for our ebuilds, they wound up
> in the portage src for lack of a better place, which I view as the wrong
> location.
> 
> Ebuild-base.eclass would hold econf, emake, ins*, and a few other
> functions.
> 
> Assuming people have read this far, and agree, and this is actually
> undertaken, the scripts/ebuild-base class should be controlled by a
> herd- those who know the tree in and out would be best for the herd.
> Basically, grab those who already are already doing serious QA of the
> ebuilds in the tree.
> 
> As for actually doing these moves, it's pretty straightforward. 
> Transferring the scripts out of portage pretty much consists of a PATH
> addition in a portage release, for auto-inheriting ebuild-base.eclass,
> addition of another src statement.  About it.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Brian Harring]

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

On Jul 29, 2004, at 11:33 AM, Cory Visi wrote:

> Theory aside, it really sounds like your two examples and everyone 
> else's
> follow-ups have do to with the QA time on portage releases.

The amount of time between portage releases is a factor in people 
supporting this, no doubt.

>  The real problem is not that these utilities are part of portage 
> releases, but that
> portage releases take too long to come out.

Unless someone can give me a valid reason why this functionality must 
be bundled, then no, that isn't the problem- the problem is that they 
- -are- bundled with portage.

These utilites are specific to our tree, and should be correct for the 
tree *at that moment*.  I really am not fond of the notion that, while 
the ebuild may be correct, the portage version's bundled utilities are 
broke so the ebuild misbehaves.

> Is moving them into the portage tree so every developer can have at it 
> the
> right solution? Will QA on these "base" utilities be neglected?

The scripts in question are rather simple.  The bash functions too, are 
simple, and rarely changes between releases.  In other words, 
maintaining them isn't a pita, far from it.
If they are split out of portage and into the tree, it doesn't 
automatically mean that there isn't going to be any QA applied- if that 
were true, eclass's would be a colossal failure, and would be bundled 
with portage.

Besides, it's not like having this code in portage has somehow 
protected them from bugs. :)

>  How can we
> assure the same type of care with these utilities is taken as with 
> portage
> releases?

Again, look at our eclasses.  The amount of damage a dumb dev could do 
is staggering, yet we have little to no problems w/ them.  Why?  
Because releasing a fix is pretty much instantaneous, and any dev in 
that herd can do it.  Somebody makes a mistake in an eclass, we can fix 
it right then and there, and only wait a max of an hour for the fix to 
hit the mirrors.
With a portage release, it takes quite a bit longer.

In terms of who has access to modify this code, I already talked with 
genone regarding this.  We use the same type of access control we do on 
eclassess- "soft" access control, fex we break your knees if you commit 
to them and aren't a member of the herd.

If the threat of bodily harm isn't enough, we implement access control 
in cvs.

> I'm not against this move, I just want to discuss these issues.
Valid issues :)
Hopefully I've addressed the issues you raised adequately.
~brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBCUTXvdBxRoA3VU0RAmKpAJ9mIzToYO+fwBmCeeMhP5BWxDvxpwCbBso4
TUrxn1bATGYqMPg1yKdF20k=
=lDQh
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Jason Stubbs]

On Friday 30 July 2004 03:41, Brian Harring wrote:
> Unless someone can give me a valid reason why this functionality must
> be bundled, then no, that isn't the problem- the problem is that they
> -are- bundled with portage.

Not from me.

> These utilites are specific to our tree, and should be correct for the
> tree *at that moment*.  I really am not fond of the notion that, while
> the ebuild may be correct, the portage version's bundled utilities are
> broke so the ebuild misbehaves.

This is the only valid reason I've heard. However, what about the other way? 
An ebuild is installed and goes to be unmerged but the support functions used 
during prerm have changed slightly causing it to break. I realize this is an 
issue anyway, but one that hasn't cropped up yet.

Code-wise, there are two possibilities. One is to bundle the support functions 
into the saved environment and the other is to not. Not bundling allows the 
possibility above. Bundling leads to the possibility that an ebuild is 
installed with a broken function (that is only used during prerm) that has no 
way of being fixed.

The fix? I'd say to make sure the behaviour of every function is well 
documented and ensuring that the behaviour doesn't change in general. I 
presonally think that any extension would normally warrant a new function so 
that ebuilds know exactly what they're getting. However, even if that's not 
adopted, having the documentation means that any extension can be better 
audited.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Brian Harring]

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

On Jul 29, 2004, at 6:19 PM, Jason Stubbs wrote:
>> These utilites are specific to our tree, and should be correct for the
>> tree *at that moment*.  I really am not fond of the notion that, while
>> the ebuild may be correct, the portage version's bundled utilities are
>> broke so the ebuild misbehaves.
>
> This is the only valid reason I've heard. However, what about the 
> other way?
> An ebuild is installed and goes to be unmerged but the support 
> functions used
> during prerm have changed slightly causing it to break. I realize this 
> is an
> issue anyway, but one that hasn't cropped up yet.

Script arguments (so far) have always maintained backwards 
compatibility- regardless of the location the script is stored in (or 
where it comes from), the maintaining backwards compatibility of 
arguments is an issue.

>
> Code-wise, there are two possibilities. One is to bundle the support 
> functions
> into the saved environment and the other is to not. Not bundling 
> allows the
> possibility above. Bundling leads to the possibility that an ebuild is
> installed with a broken function (that is only used during prerm) that 
> has no
> way of being fixed.

The issues you're raising are more so related to my env save/restore 
code in bug #56408, then this thread.
Currently, portage re-sources the ebuild (and eclasses) at every step- 
the env is reloaded, but all functions are overwritten (along with 
small # of vars). A borked function saved in the env is overwritten by 
ebuild.sh, and would be even if we split off an ebuild-base.eclass .  
Course as you pointed out, the converse of this is that a borked 
function in the current portage version would override the correct 
version in the saved env.

> The fix? I'd say to make sure the behaviour of every function is well
> documented and ensuring that the behaviour doesn't change in general.

Changes in function behaviour would be possible if the env handling 
I've setup in bug #56408 was in portage- by saving the function w/ the 
ebuild, you're basically taking a snapshot of everything at that point. 
  As long as the tree has been updated prior, changes to functions (such 
as the use_enable/use_with change in .51) wouldn't have to worry about 
screwing up prerm's of installed ebuilds.
That said, it's a separate issue from splitting scripts/functions out :)

> I presonally think that any extension would normally warrant a new 
> function so
> that ebuilds know exactly what they're getting. However, even if 
> that's not
> adopted, having the documentation means that any extension can be 
> better
> audited.
Current portage, yeah, changes to ebuild.sh functions that ebuild's 
directly call should be limited to bug fixes- *never* changing default 
behaviour.
Basically the issues you raised above is why I did the env handling 
code in bug #56408, that and ebuilds expecting 
export'd/readonly/declare -i'd variables to retain their original 
attributes across ebuild phases.

For commentary above, I've assumed you're talking about bash 
functionality- if you're referring to the scripts in bin/*, we've yet 
to bundle those w/ an installed ebuild.  Possible I spose, although 
again, that falls under another thread/bug; it would be an extension of 
portage's env snapshot code, and wouldn't care about where it got the 
scripts from, just as long as it could find them :)
~brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBCZvxvdBxRoA3VU0RAmbzAKDQII3D5qhv3CONhvh/ExSbjsiJBwCglrpk
hNZgSaUIO3h18bb4prnqCWY=
=YwaB
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Jason Stubbs]

On Friday 30 July 2004 09:53, Brian Harring wrote:
> For commentary above, I've assumed you're talking about bash
> functionality- if you're referring to the scripts in bin/*, we've yet
> to bundle those w/ an installed ebuild.  Possible I spose, although
> again, that falls under another thread/bug; it would be an extension of
> portage's env snapshot code, and wouldn't care about where it got the
> scripts from, just as long as it could find them :)

I assumed that, with the moving of most of bin/*, everything would go into one 
(or more) eclass(es). At least, that seems the most convenient way to me. Do 
you have a fairly clear view in mind of exactly what would stay and what 
would be moved yet?

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Mike Frysinger]

On Friday 30 July 2004 11:15 am, Jason Stubbs wrote:
> I assumed that, with the moving of most of bin/*, everything would go into
> one (or more) eclass(es). At least, that seems the most convenient way to
> me. Do you have a fairly clear view in mind of exactly what would stay and
> what would be moved yet?

i can think of a good and a bad reason for keeping these definitions in a bash 
script ...
good: we can stick 'die' in some of the core functions (epatch)
bad: we cant run the functions through another binary (like env)

i dont think the bad has caused much issues before so i'd like to keep the 
behavior that things (like epatch) have
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Aron Griffis]

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

Vapier wrote:	[Fri Jul 30 2004, 12:15:52PM EDT]
> good: we can stick 'die' in some of the core functions (epatch)

Btw, in the past I've been against this sort of thing.  Bash-3.0 seems
to have the ability to generate a stack trace (I haven't tried it
yet), so I'm much more in favor now that we can trace back to the
original line in the ebuild.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Brian Harring]

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


On Jul 30, 2004, at 10:15 AM, Jason Stubbs wrote:

> On Friday 30 July 2004 09:53, Brian Harring wrote:
>> For commentary above, I've assumed you're talking about bash
>> functionality- if you're referring to the scripts in bin/*, we've yet
>> to bundle those w/ an installed ebuild.  Possible I spose, although
>> again, that falls under another thread/bug; it would be an extension 
>> of
>> portage's env snapshot code, and wouldn't care about where it got the
>> scripts from, just as long as it could find them :)
>
> I assumed that, with the moving of most of bin/*, everything would go 
> into one
> (or more) eclass(es). At least, that seems the most convenient way to 
> me.

Viable for the bash based scripts, although my original plan had been 
just to move them into the tree in their current form.
Changes down the line to how they are stored, eg- if they are kept as 
they are, if they are stored in one giant script, if we have them 
source as actual bash functions, etc, is a bit dependant on if the env  
saving/restoring mechanisms are cleaned up.  Until ebuild.sh correctly 
preserves the env's attributes, and stop's overwriting portions of it 
by default, I'd prefer to keep the scripts as they are.
Besides, the move is the big thing.  With that out of the way, it's 
upto the new herd to determine how it's arranged/handled (within limits 
of course).

>  Do
> you have a fairly clear view in mind of exactly what would stay and 
> what
> would be moved yet?
For scripts, everything.
For bash functions, that's a bit trickier.  Note, we don't have to move 
*everything* in a giant exodus, things can be shifted out down the 
line.
That said, these come to mind.

econf, emake, einstall, einfo, ewarn,
use, usev, use_enable, use_with,
pkg_pre*, pkg_post*, pkg_fetch, pkg_nofetch,
src_unpack, src_compile, src_install, src_test,
has, hasv,
enable_qa_interceptors, disable_qa_interceptors,
*opts functions,
*into functions,

That should *roughly* cover it.  Once carpaski speaks up on this 
(yay/nay), I can go through and build a final list.
~brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBCyPtvdBxRoA3VU0RAq/7AKCvoghoFMtFwQQrIYzS2XZFw4vSSQCggkzA
32pKiEvcZLTcTESWBVijCaw=
=s8hS
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Ned Ludd]

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

I fully support this as long as I'm in said group that can commit on
these things or get a speedy response from somebody else that is. 
If initially if it's going to be limited I'd suggest the base-system,
portage and toolchain herds.

I'm also in favor of moving not just the do* stuff but also much of the
prep* that can be safely moved out of
/home/cvsroot/gentoo-src/portage/bin/ as well.

Thank you ferringb for mustering up this email to shed light on the
situation.

On Thu, 2004-07-29 at 05:36, Brian Harring wrote:
> Note: pardon the dual post, resending this since I managed to leave a
> subject off of... any discussion regarding this, please start the thread
> from this message... sorry about that :-)
> 
> Currently portage bundles all do* and new* scripts that ebuilds use with
> each release.  In other words, the current breakage w/ dohtml -R not
> handling files w/ spaces correctly is tied to a portage version
> (<=.51_pre13).  Prior releases of portage will remain broke,
> since the fix is tied to a portage release.
> 
> To head off the 'they should upgrade', yes, having a current portage is
> important- that doesn't mean we can't split these files out so that they
> *aren't* tied to a release.
> 
> Gentoo's pkg system is basically composed of two things; portage, the
> executor of ebuild instructions, and the tree, the data for
> compilation/installation of src.  Currently portage is basically
> providing a collection of scripts/functions that are strictly used by
> the ebuilds, basically a library of functions/scripts- basically 'data'
> in the exec portion.
> 
> This 'library' should be placed into the tree, since portage isn't aware
> of the scripts/functions even existing for the most part.  The do* and
> new* scripts are specific to the customs we have for our tree, not
> portage.
> 
> The scripts are kind of a no brainer for moving- what I'm also
> proposing, is the creation of an ebuild-base eclass that is
> automatically inherited, and lives in the tree.
> 
> Same thing, moving functions out of portage that are specific to our
> tree, into the tree.
> 
> Fex: the amd64 crew is after being able to overload econf so that they
> can specify where the 64bit libs should live; as it stands, they're
> stuck until it's in a portage release.  If econf lived in the
> ebuild-base class, this change could be flipped on regardless of the
> users portage version.
> 
> The embedded crew are after something similar- see bug #55476, basically
> need an addition to econf to do tweaks to configure scripts; as it
> stands, they must wait for it a release.
> 
> The point of all of this is that these functions/scripts *aren't*
> specific to portage the package, they're specific to our tree,
> specifically the tree *at that moment*  I'd assume when it was decided
> we would have these functions available for our ebuilds, they wound up
> in the portage src for lack of a better place, which I view as the wrong
> location.
> 
> Ebuild-base.eclass would hold econf, emake, ins*, and a few other
> functions.
> 
> Assuming people have read this far, and agree, and this is actually
> undertaken, the scripts/ebuild-base class should be controlled by a
> herd- those who know the tree in and out would be best for the herd.
> Basically, grab those who already are already doing serious QA of the
> ebuilds in the tree.

> As for actually doing these moves, it's pretty straightforward. 
> Transferring the scripts out of portage pretty much consists of a PATH
> addition in a portage release, for auto-inheriting ebuild-base.eclass,
> addition of another src statement.  About it.
> 
> So... thoughts?
> ~brian
-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Jason Stubbs]

On Friday 30 July 2004 03:54, Ned Ludd wrote:
> I fully support this as long as I'm in said group that can commit on
> these things or get a speedy response from somebody else that is.
> If initially if it's going to be limited I'd suggest the base-system,
> portage and toolchain herds.

I would personally like a new herd that is relatively small. The worst thing 
that I can see happening by having these functions managed outside of portage 
is that they become full of "if arch is this" or "if use has that". Adding 
that sort of code would enable quick fixes now but would make things harder 
to maintain in the long run, eventually creating a situation that is worse 
than what we have now.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving functionality out of portage and into the tree

[Donnie Berkholz]

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

On Thu, 2004-07-29 at 14:54, Ned Ludd wrote:
> I fully support this as long as I'm in said group that can commit on
> these things or get a speedy response from somebody else that is. 
> If initially if it's going to be limited I'd suggest the base-system,
> portage and toolchain herds.

I'd suggest adding the qa herd/project/whatever to this list. Hopefully,
they all have a solid grasp of how things work. (If they didn't, how
could they do QA?)
-- 
Donnie Berkholz
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]