Gentoo Archives: gentoo-portage-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Moving ebuild-related where they belong
Date: Fri, 08 Sep 2006 23:29:11
Message-Id: 4501FC74.7040705@gentoo.org
In Reply to: Re: [gentoo-portage-dev] Moving ebuild-related where they belong by Alec Warner
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 Alec Warner wrote:
5 > Zac Medico wrote:
6 >> Incompatible changes for a given EAPI specification are simply unacceptable.
7 >> People really should know better than that. If not, educate them.
8 >>
9 >
10 > See this is a bad idea. If you give them a hand, they take the whole arm...
11 >
12 > You don't presently export a ton of stuff to developers for their
13 > tinkering (bashrc aside, that affects them locally only). The bad part
14 > being you get to maintain it; the good part being you also have full
15 > control of what goes on.
16
17 But you don't have absolute control. This is free software, and people can
18 always fork or create an entirely new package manager (paludis and pkgcore,
19 anyone?) that has EAPI differences (subtle or not so subtle). By moving the
20 EAPI support into the tree, it allows different package managers to share the
21 same EAPI support code.
22
23 > Once that control is gone you can't really
24 > guarantee much...."Just educate them" means that 50% of developers will
25 > have NFC what EAPI means and the other 50% will break it because it
26 > helps make their job easier. Just as when you add functionality now
27 > with no EAPI bump; it often gets used immediately (although thank god
28 > most people are smart enough to add the correct DEPEND statements). You
29 > give up that control and you end up with another large area of the tree
30 > to QA and no real way to do so.
31
32 I'm not convinced that this type of restriction of freedoms is the best way to
33 go about preventing EAPI breakage. Perhaps there should be a special herd that
34 maintains the EAPI specific portions of the tree. A similar type of API
35 breakage can already occur via eclasses, so I'm not seeing a big difference here.
36
37 Zac
38 -----BEGIN PGP SIGNATURE-----
39 Version: GnuPG v1.4.5 (GNU/Linux)
40
41 iD8DBQFFAfxy/ejvha5XGaMRAuWpAJ9Niew8KSeBqsjIKkOBNHRxlQIfYgCguELD
42 XscxgIQ0I8mq8rYfF3GMikY=
43 =DL/m
44 -----END PGP SIGNATURE-----
45 --
46 gentoo-portage-dev@g.o mailing list