1 |
2007/12/18, Joe Peterson <lavajoe@g.o>: |
2 |
> Santiago M. Mola wrote: |
3 |
> >> One example was mentioned in this thread before: You cannot use |
4 |
> >> "find -name '*.ebuild'" anymore. |
5 |
> >> |
6 |
> > |
7 |
> > So people could use a bit more elaborated expression to find them. |
8 |
> > Things like this shouldn't be a reason for not applying |
9 |
> > EAPI/GLEPs/PM-behaviour changes. If this GLEP is approved, it would be |
10 |
> > fine to publish a quick guide of recipes to migrate scripts which rely |
11 |
> > on the old naming convention and that should be enough. |
12 |
> > |
13 |
> > IMO, keeping us away from improvements to Gentoo because they break |
14 |
> > backwards compatibility with third party scripts is a no-go. Of |
15 |
> > course, this kind of changes can't happen once a month, but they can |
16 |
> > happen from time to time. |
17 |
> |
18 |
> I don't think this is about strictly maintaining backwards |
19 |
> compatability. You are right that we should not let this impede |
20 |
> progress. My objection is that the proposed scheme does not appear to |
21 |
> make the system more elegant, but rather it creates complexity, |
22 |
> potential errors (mismatches in representions of EAPI), and introduces a |
23 |
> rather unorthodox and complicated file extension pattern. |
24 |
> |
25 |
> I also do not see why there are not other more elegant, transparent, and |
26 |
> automatic ways to determine EAPI without sourcing. I put forth an idea, |
27 |
> and I understand the objections to it, but I'm just brainstorming, and |
28 |
> there *must* be other ways that retain portage's elegance and simplicity. |
29 |
> |
30 |
> -Joe |
31 |
> -- |
32 |
> gentoo-dev@g.o mailing list |
33 |
> |
34 |
> |
35 |
|
36 |
Just another brainstorming attempt. Is it possible to use one single |
37 |
file per eapi which lists all ebuilds using a specific eapi like |
38 |
package.eapi-name and is stored in the profiles. Or even one single |
39 |
file which lists the ebuild and its eapi. |
40 |
-- |
41 |
gentoo-dev@g.o mailing list |