| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Petteri Räty wrote: |
| 5 |
> 3) EAPI in locked down place in the ebuild |
| 6 |
> c) .ebuild in current directory |
| 7 |
> - needs one year wait |
| 8 |
|
| 9 |
I'm all for 1 or 3c, because we're not in any rush. |
| 10 |
|
| 11 |
I don't see why there's such an immediate need to make as drastic |
| 12 |
changes as are being suggested for GLEP-55, simply to allow for the |
| 13 |
possibility of future unknown ebuild mechanisms (like ebuilds not being |
| 14 |
bash scripts). If ebuilds change significantly from their current form, |
| 15 |
then and only then, would it be a good time to change the ebuild suffixes. |
| 16 |
|
| 17 |
I don't want to get an attachment from bugzilla and find I have to try |
| 18 |
four different file extensions because whilst the package and version |
| 19 |
were obvious from the bug, the eapi number wasn't. |
| 20 |
|
| 21 |
I also don't want to run into a situation where this package manager |
| 22 |
supports kdebuilds, whilst that package manager supports gnomebuilds, |
| 23 |
and a third one supports xfcebuilds. That's just recreating the browser |
| 24 |
wars, and will leave us with the likes of IE6. |
| 25 |
|
| 26 |
I'd be relatively happy with a shebang that specifies the parser or |
| 27 |
passes the ebuild version, as long as it was standardized, linear and |
| 28 |
supported by all the PMs (ie, some rogue PM can't suddenly start |
| 29 |
allowing a "myeapi" that only it can build)... |
| 30 |
|
| 31 |
Mike 5:) |
| 32 |
-----BEGIN PGP SIGNATURE----- |
| 33 |
Version: GnuPG v2.0.10 (GNU/Linux) |
| 34 |
|
| 35 |
iEYEARECAAYFAkmlKQEACgkQu7rWomwgFXoRFACdHfDHuHhj7ojsQV5FvF+rRpRT |
| 36 |
PgQAoKTq6iAmNLC50a97JHrQghRZK6O0 |
| 37 |
=ELuP |
| 38 |
-----END PGP SIGNATURE----- |
Archives