| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Brian Harring wrote: |
| 5 |
> Just so we're clear... if gentoo-x86 wants to define their own base |
| 6 |
> template all ebuilds in that repo use, that's fine. That's a |
| 7 |
> different beast from moving the format definition into the tree |
| 8 |
> though. |
| 9 |
> |
| 10 |
> Kind of curious if either of you have thought through the implications |
| 11 |
> of moving this functionality into the tree for the vdb and binpkgs |
| 12 |
> also (short version, even with ebds env handling its not going to be |
| 13 |
> pretty for backwards compatibility). |
| 14 |
|
| 15 |
Since incompatible changes require an EAPI bump, backward compatibility is |
| 16 |
automatically handled by EAPI. |
| 17 |
|
| 18 |
>> Fine, but the EAPI can still be used to imply that some other functions may or |
| 19 |
>> may not be available. |
| 20 |
> |
| 21 |
> Not really. Via moving parts of the format into gentoo-x86 it's |
| 22 |
> implciitly setting it up such that whatever tree portage is working |
| 23 |
> against now defines EAPI. |
| 24 |
> |
| 25 |
> Sounds whacky, but think it through; instead of trying to verify that |
| 26 |
> 3 package managers are EAPI compliant, it's now dependant on the |
| 27 |
> environment the tree defines, as such the tree can redefine the env |
| 28 |
> without bumping the EAPI. |
| 29 |
> |
| 30 |
> Yes that's stupid to do, but moving the format into the tree enables |
| 31 |
> it. Theres a reason no other package format has their actual format |
| 32 |
> definitions (env setup in our case) shoved into the repo, and thats |
| 33 |
> one of them. |
| 34 |
|
| 35 |
Incompatible changes for a given EAPI specification are simply unacceptable. |
| 36 |
People really should know better than that. If not, educate them. |
| 37 |
|
| 38 |
>>> Actually, the reason they won't like it for will more likely be that it |
| 39 |
>>> requires adding another eclass to the inherit line for ~15'000 ebuilds. |
| 40 |
>> See, that statement shows me that you've missed my point that EAPI can be used |
| 41 |
>> to imply which functions are implicitly available. It would be redundant to |
| 42 |
>> inherit an eclass containing functions that are already implied by the EAPI. |
| 43 |
> |
| 44 |
> Would require 24,600 (last count) mods to ebuilds to specify an elib |
| 45 |
> import moreso; automagically trying to import an elib out of a |
| 46 |
> repository is pretty much guranteed to not behave as desired (overlays |
| 47 |
> again come to mind). |
| 48 |
> |
| 49 |
> Eclasses are designed as crappy oop; what this change means for |
| 50 |
> eclasses/elibs is that instead of reusing functionality, functionality |
| 51 |
> gets copy/pasted across repositories- not a good thing. |
| 52 |
> |
| 53 |
> ~harring |
| 54 |
|
| 55 |
We can design it to be overlay friendly. An overlay can be viewed as a child |
| 56 |
derivation of a parent repo. The child inherits from the parent and can |
| 57 |
override it. |
| 58 |
|
| 59 |
Zac |
| 60 |
-----BEGIN PGP SIGNATURE----- |
| 61 |
Version: GnuPG v1.4.5 (GNU/Linux) |
| 62 |
|
| 63 |
iD8DBQFFAcwM/ejvha5XGaMRAntEAJ48SPKfOn6Ar+e57qyG+VTznVtppgCgpDiO |
| 64 |
Pra2VFJsst4N9dxXIBzWtzo= |
| 65 |
=MzKj |
| 66 |
-----END PGP SIGNATURE----- |
| 67 |
-- |
| 68 |
gentoo-portage-dev@g.o mailing list |
Archives