Jorgen Schaefer <firstname.lastname@example.org> writes:
> If you plan on "packaging third-party packages" for scsh, that is,
> modifying some other source, it might be useful to plan ahead to
> such needs as saying "damn, my first attempt to package had a bug, I
> have to package it again, but the upstream version didn't change".
True. There is at least one such package definition for a third-party
package (SSAX), and with the current scheme we cannot version the
package definition independently.
It could be a good idea to have a way to version these, but that
version should be optional, as in most of the cases it is constant (as
the package definition is bundled with the package itself). We could
use the underdash here, and say that if no underdash appears, then the
package version defaults to 1. So "my-lib-4.9_1" would be the same as
"my-lib-4.9", and both would designate the first version of the scsh
package for version 4.9 of the library "my-lib". This naming scheme
would be a bit counter-intuitive to people used to the Debian naming
scheme, but it's backward-compatible...
> That is, compared to your idea, Debian also allows the plus sign and
> the dot.
Yes, for now I think it's fine to go on with what we have, and we can
always widen the rules later should the need arise.
>> Would that change be acceptable for you (and for others)? If it
>> is, I'll incorporate it in the next release, hopefully with an
>> initial (simple) support for dependencies.
> As long as dashes and ASCII-alphanumeric stuff is allowed, I'm a
> happy user :-)
Good, then I'll make the described changes in the next release of the
proposal. I don't want to make a release just for that, but in the
meantime you can consider that the new rules apply (these rules are
currently for humans only, anyway, no piece of code relies on them
[but that could change soon]).