Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds
On 13-11-2009 12:43:25 +0100, Ulrich Mueller wrote:
> In its November meeting [1], the council has unanimously expressed
> support for this proposal [2].
>
> However, there is need for additional discussion. From the council
> meeting log I could extract the following open questions:
>
> 1. What are the implications for non-prefix devs and users?
for devs: take note of EPREFIX, ED and EROOT, be aware what they mean
and eventually, use them in the right way. This is not hard, since a
simple script[3] based on some heuristics can do the work in 98% of the
cases right.
for users: not an single bit, unless they look inside ebuilds
> 2. Should the Prefix team be allowed to do the necessary changes to
> ebuilds themselves, or should it be done by the respective
> maintainers?
The Prefix team is the equivalent of an arch team, only handling a big
bunch of arches [4]. Hence, keywording should be out of the question,
and just allowed. Adding simple patches (to normal non-critical
ebuilds) used to be allowed AFAIR, so I see that as ok too. In other
words, like darkside mentioned, I see our activities like those of an
arch team.
> 3. Are there any backwards compatibility or upgrade path issues for
> eclasses that must still accept EAPI 0 (where the new ED, EROOT,
> and EPREFIX variables are not defined)?
The backward and forward compatability is handled with conditional
code like:
use prefix || local ED=${D}
or
[[ -z ${ED} ]] && local ED=${D}
Since Zac checked in yesterday blacklisting of EPREFIX, EROOT and ED in
the main Portage branch, these variables hopefully soon become protected
in the sense that an externally set ED does not result in weird
behaviour of a Prefix aware eclass or ebuild when using the latter
approach, which is true forward compatible.
For your information, this was exactly what I asked for from the council.
> 4. EAPI numbering: Would this simply be added as an additional
> feature to EAPI 3? Or should we have an intermediate EAPI slot,
> e.g. 2.1 or 3 (and current EAPI 3 renamed to 4 in the latter
> case)?
I don't care about this, but a fast EAPI is necessary to 1) rely on ED not
coming from outside, and 2) since we're defining ED, EROOT and EPREFIX
anyway, initialise ED and EROOT such that we don't need any conditional
code in ebuilds at all (and can just use ED where necessary).
> 5. Who is going to write the exact specification (PMS patch) for
> this EAPI feature?
We agreed that I/Prefix team will give this a shot.
> 6. (Any question that I've missed?)
I guess most additional questions go beyond, and actually address the
real Prefix work, and its implications to Gentoo and many ebuilds, since
we have to touch around 2300 ebuilds, most with trivial changes, some
with heavy changes (think of the 32 patches that one needs to compile
Python...)
> Let's start the discussion now, in order to work out these details
> before the next council meeting (December 7th).
>
> Ulrich
>
> [1]
> (topic was discussed from 21:32 to 22:11 in the log's timezone)
> [2]
>
>
[3]
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/scripts/eapify
[4] http://stats.prefix.freens.org/keywords-packages.png
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds
On 19-11-2009 19:42:11 -0600, Jeremy Olexa wrote:
> Some questions answered. snipped the rest.
readded questions where necessary
> Denis Dupeyron wrote:
> > 2009/10/18 Tomáš Chvátal :
> >> Why on earth portage simply does not detect the prefix enviroment is being
> >> run
> >> and then INTERNALY switch D->ED and other variables.
> >
> > If that means we can get away without touching ebuilds, apart from
> > changing their EAPI variable, then that's absolutely what we have to
> > do. I'd like things to be done the right way though (see below).
>
> When you change econf to do --prefix=${EPREFIX}/usr then you cannot
> simply s/D/ED/ for everything. I hope this makes sense when you think
> about it. ;)
>
>src_install() {
> emake DESTDIR="${D}" install || die
> mv "${ED}"/usr/bin/{,exuberant-}ctags || die
>}
>
> But then again, some ebuilds need no changing once you fix econf to do
> the work, which is nice.
>
> >
> > On Fri, Nov 13, 2009 at 4:43 AM, Ulrich Mueller wrote:
> >> However, there is need for additional discussion. From the council
> >> meeting log I could extract the following open questions:
> >
> > It would be preferable for the discussion to happen on this list
> > before the meeting or we'll end up postponing again due to having more
> > questions coming up at that time.
>
> We are willing to talk, but it always seems like the Council is "not
> prepared" no matter what we do. Hope everyone involved can change that.
>
> >
> >> 2. Should the Prefix team be allowed to do the necessary changes to
> >> ebuilds themselves, or should it be done by the respective
> >> maintainers?
> >
> > I think here it's obvious that anybody who is an ebuild dev and sees
> > anything to fix (prefix or else) is encouraged to go ahead and do it,
> > as we've always done. The recommendation is and will always be to talk
> > to the current maintainers out of politeness and to be extra careful
> > (i.e. usually letting the maintainers do it) in case of
> > system/tricky/exotic package. We don't give full cvs access to the
> > whole tree to all ebuild devs for nothing.
>
> It is quite obvious that we are not trying to make trouble. Talk is
> cheap, so we prefer that. But, we see no need to ask permission to add
> ~prefix keywords, same as other arch teams.
>
> Currently, 'repoman -d full' will fail in some packages. We are fixing this.
> > 4. EAPI numbering: Would this simply be added as an additional
> > feature to EAPI 3? Or should we have an intermediate EAPI slot,
> > e.g. 2.1 or 3 (and current EAPI 3 renamed to 4 in the latter
> > case)?
>
> Here I'd add to the choices: why not release an intermediate EAPI with
> the prefix stuff and whatever that has already been done for EAPI3?
> The exact name of a potential intermediate EAPI is a non-problem.
> However I would prefer if it were a number like 2.1 or 2.5 or even 3,
> because although we currently treat the EAPI variable as a simple
> string we may change our mind later and find it handy someday to use
> operators on them such as >=3D2.1.
While I think that this is a totally different discussion, unrelated to
Prefix (well, on a side-note, we once had things like EAPI="prefix 1",
which denoted both the features from "prefix" and "1"), it is good to
isolate things such that it is obvious what an EAPI stands for.
> > 5. Who is going to write the exact specification (PMS patch) for
> > this EAPI feature?
>
> I thought I asked Fabian to work on that at the end of the meeting. In
> case I didn't then consider this as me officially asking him if he can
> take care of it. Fabian is this OK with you?
Yes, I agreed coming up with some patch. I admit I haven't yet even
looked into it.
> Also I think it would be nice if somebody took care of a portage
Technically, Portage trunk already contains the most important bits that
allow us to continue since yesterday. The rest is waiting for a formal
approval of the council, and then it will most probably be me and Zac
fighting to get the prefix branch merged into trunk.
> > patch, since I hear it is rather simple. Fabian again? Or Zac? Any
> > other volunteers?
> >
> > I would prefer to have all the pieces in places before the next
> > meeting so that we can vote on the real thing and have prefix
> > implemented the right way before the end of the year.
>
> portage devs and prefix devs have agreed that it is rather 'easy' to
> merge the prefix-portage branch. Just waiting.. ;) We have access to
> check into the portage repo, so this should not hold anything up
> regarding any decisions.
just to repeat: the implementation already exists in the "prefix" branch
of the portage repository.
> >> 6. (Any question that I've missed?)
>
> >> How are scripts using #!shebangs going to work?
> >> You write an ebuild, and you DEPEND upon >=foo-3, because the build
> >> process includes some foo code. The foo code is executed via
> >> scripts using #!/usr/bin/foo. N
Re: [gentoo-dev] Last rites: app-emacs/ngnus
> "Ulrich" == Ulrich Mueller writes: >> (A rename to app-emacs/gnus- is OK, Ulrich> Done so. Thanks for the feedback. >> provided it gets mentioned in profiles/updates.) Ulrich> It's technically not possible to do a "partial package Ulrich> move". But I'd expect users of live ebuilds to be able Ulrich> to figure things out by themselves. I took a look at one of the upates files before repying and noticed a $P or two, not just $PN. But on closer exam I see that those are for slot moves Thanks. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
