Alec Warner wrote:
On Mon, Jan 26, 2009 at 8:01 PM, Jeremy Olexa <darks...@gentoo.org> wrote:
Jorge Manuel B. S. Vicetto wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Donnie Berkholz wrote:
On 21:04 Sun 25 Jan     , Ciaran McCreesh wrote:
On Sat, 24 Jan 2009 20:25:44 -0100
"Jorge Manuel B. S. Vicetto" <jmbsvice...@gentoo.org> wrote:
I talked to Zac <zmedico> earlier in #gentoo-portage about adding an
entry to package.mask for KDE-4.2.0 using slot deps. Thomas
<tanderson> and Patrick <bonsaikitten> raised the concern we might
need profile eapis and that PMS nailed p.mask to EAPI-0.
Zac confirmed that the first stable version to support slot deps in p.
mask was 2.1.3.16, that it was stabled in bug 197165 - 14 months ago
- - and that the first stages to include it were the 2008.0 stages.
Thus, can we finally give the ok to use slot deps in package.mask? Can
we also give the ok to use it everywhere in all 2008.0 and later
profiles/ ?
The Council approved profile eapi files for use a while ago (can't
remember when -- http://council.gentoo.org/ isn't being updated), and
Last month's meeting

they discussed timeframes for using newer EAPIs then too. Did you see
that discussion?
"An EAPI=0 profile always needs to exist so that users with old portage
can upgrade. Otherwise they will sync and have no valid profile available so
cannot emerge a new version of portage.

"Decision: Approved. Existing stable profiles must use EAPI=0. New or dev
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
profiles can use higher EAPIs.
Acoording to this we will never be able to use slot deps in package.mask
as it's a global file. Given my first mail, can we agree to make EAPI-1
the minimum EAPI for files under profiles/ ? Can we also create a rule
on how / when to update the minimum EAPI in profiles/ ?
So, portage that is unaware of EAPI-1 will just happily ignore the atom and
move on..? In that case:

Please no! It is hard enough for a base 2007.0 install to be upgraded due to
the "portage & bash blocker" (and other issues) - We need to wait much
longer for an EAPI bump in a non-new profile (if ever, as Brian Harring
suggests - I agree).

I know this might seem as a hassle to you but there *are* other entities
that provide a base 2007.0 install. Who knows how every
group/entity/company/etc use Gentoo.. While I agree that it isn't
necessarily our problem, however, we shouldn't make it harder for them or
anyone that has a 2007 base install. (We still mirror the 2007.0 stages[1],
2007.0 cds are available[2] for purchase, etc[3] etc[4]).

Dude, even people like Ubuntu/Canonical don't support stuff that old
(current LTS is April 2008).

The tree is now; see the date?  It's 2009, not 2007.

One of the biggest problems Gentoo has is backwards compatibility and
legacy stuff; it is the nightmare of every project and there has to be
a point where you say 'tough.'  So make a decision, announce it widely
that on X date the tree will just break for users; write up a FAQ on
how to upgrade past it, and then make the changes.

2008.0 was released on Jul 6 2008[1]. So, you think that after 6 months, it is time to say "tough"? Sorry, I don't agree.

[1]: http://www.gentoo.org/proj/en/releng/release/2008.0/index.xml#doc_chap2


Realize once again that the tree was not designed very well and it has
issues on a number of levels and it can't all be engineered around;
and for progress to be made you will *have to break existing stuff*.

IMO, it would be a dis-service to bump EAPI in a non-new profile for our
user-base. I don't see any Pro's besides "easier to type" =/ So, I think the
Council decision is appropriate.

You seriously see no benefits to EAPI 1 or 2 in profiles?  What about
slot deps? use deps? these things have been core feature requests
since 2003; surely you don't think they are useless to our users?

No, I didn't say that at all, *sigh*


-Jeremy

[1]: http://distfiles.gentoo.org/releases/x86/2007.0/
[2]: http://www.linuxcd.org/view_distro.php?lst=&id_cate=20&id_distro=12
[3]: http://lylix.net/linux-vps-plans
[4]: http://www.linode.com/faq.cfm




Reply via email to