-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Piotr Jaroszyński wrote:

> I think what you are missing is that some people (me included) think
> that the in-file approach is the cleanest and most obvious solution
> (which also happens to not hurt performance). So if you want "bad
> design" to be an objective argument you need to back it up with
> something concrete. For example, could you foresee any actual problems
> of the in-filename approach? Cause all I was hearing was "it doesn't
> look nice" which now is "oh no, don't expose metadata". The former is
> clearly subjective and the latter is already done ($PN-$PV) and
> doesn't seem to cause any problems.

What we care about doing is being able to install a package of a known name, PN,
with a known version, PV, and we may even want to make sure that the revision,
PR, is just right. Therefore PN, PV and PR are not metadata, but actual data to
identify a specific software unit. (This is also why PR should be bumped if (and
mostly only if) there are changes to files that will be installed.)
On the other hand, EAPI is a value that encodes what is valid in an ebuild and
as such is an implementation detail. Exposing implementation details is bad 
design.

Actually I think just changing extensions is also an implementation detail. If
we need the user to make certain upgrades (portage, bash) before being able to
use certain ebuilds then we should just tell them. What else are news items for?
As long as we provide an upgrade path from version X_years_old to version
X_days_old via versions A, B and C, I think we have done our part. In fact we
already had one such situation with bash and portage.

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkofqY4ACgkQp/VmCx0OL2xOLQCgqkXnwaThpT2oOdpiliS7SHRa
pt8An3/S6O+LiXkzQBRPsw0zRUmxhNZp
=Ntpj
-----END PGP SIGNATURE-----

Reply via email to