Steven J Long wrote:
Getting into a nonsensical debate about PN being metadata seems to be
the level of the argument, so forgive me for not being very impressed.
(It's externally derived and in fact the whole point of the product;
unless someone is proposing losing PN and PV from filename, can we
*please* dismiss that argument as the irrelevance which it is?)
Without actually intending to open a new debate on that issue <cringes>,
I'm actually a fan of NOT obtaining PN and PV from the filename. I've
seen an approach like this used in various systems and I happen to like it:
1. First, I don't propose ebuild names should change at all. By all
means we should continue to leave PN and PV in the filename since the
current naming convention makes sense.
2. However, I do propose that the package manager should ignore PN/PV
in the filename entirely.
3. Instead, the package manager will obtain PN and PV from inside the
ebuild (as ordinary shell variables). I'd even break up PV into an
upstream revision and an ebuild revision.
Once you make these changes I see these benefits:
a. You get rid of all kinds of parsing issues - like restrictions on
dashes in the various components.
b. You can more flexibly allow for all kinds of crazy upstream
versioning systems, since it isn't mashed together with the ebuild revision.
c. If somebody comes up with a more clever way to name files we can use it.
d. We can bend the rules on PN/PV/etc in the filename since it is just
a user-visible representation of PN/PV and not the source of these values.
On the other hand, a bump will require more than a cp command. There
are also increased demands on caching (similar to all the glep55
ebuild-in-file issues).
In any case, this isn't a serious proposal that needs a 47-reply debate.
Just an idea...
