Re: Package names in a proposal for scsh packages
Michel Schinz <[email protected]>
| Newsgroups | gmane.lisp.scheme.scsh |
|---|---|
| Message-ID | <[email protected]> |
Jorgen Schaefer <[email protected]> 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]). Thanks, Michel.