| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Piotr Jaroszyński wrote: |
| 5 |
|
| 6 |
> I think what you are missing is that some people (me included) think |
| 7 |
> that the in-file approach is the cleanest and most obvious solution |
| 8 |
> (which also happens to not hurt performance). So if you want "bad |
| 9 |
> design" to be an objective argument you need to back it up with |
| 10 |
> something concrete. For example, could you foresee any actual problems |
| 11 |
> of the in-filename approach? Cause all I was hearing was "it doesn't |
| 12 |
> look nice" which now is "oh no, don't expose metadata". The former is |
| 13 |
> clearly subjective and the latter is already done ($PN-$PV) and |
| 14 |
> doesn't seem to cause any problems. |
| 15 |
|
| 16 |
What we care about doing is being able to install a package of a known name, PN, |
| 17 |
with a known version, PV, and we may even want to make sure that the revision, |
| 18 |
PR, is just right. Therefore PN, PV and PR are not metadata, but actual data to |
| 19 |
identify a specific software unit. (This is also why PR should be bumped if (and |
| 20 |
mostly only if) there are changes to files that will be installed.) |
| 21 |
On the other hand, EAPI is a value that encodes what is valid in an ebuild and |
| 22 |
as such is an implementation detail. Exposing implementation details is bad design. |
| 23 |
|
| 24 |
Actually I think just changing extensions is also an implementation detail. If |
| 25 |
we need the user to make certain upgrades (portage, bash) before being able to |
| 26 |
use certain ebuilds then we should just tell them. What else are news items for? |
| 27 |
As long as we provide an upgrade path from version X_years_old to version |
| 28 |
X_days_old via versions A, B and C, I think we have done our part. In fact we |
| 29 |
already had one such situation with bash and portage. |
| 30 |
|
| 31 |
Marijn |
| 32 |
|
| 33 |
- -- |
| 34 |
If you cannot read my mind, then listen to what I say. |
| 35 |
|
| 36 |
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML |
| 37 |
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode |
| 38 |
-----BEGIN PGP SIGNATURE----- |
| 39 |
Version: GnuPG v2.0.11 (GNU/Linux) |
| 40 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
| 41 |
|
| 42 |
iEYEARECAAYFAkofqY4ACgkQp/VmCx0OL2xOLQCgqkXnwaThpT2oOdpiliS7SHRa |
| 43 |
pt8An3/S6O+LiXkzQBRPsw0zRUmxhNZp |
| 44 |
=Ntpj |
| 45 |
-----END PGP SIGNATURE----- |
Archives