Alan Barrett <apb%cequrux.com@localhost> writes:
> On Fri, 02 Mar 2012, Aleksej Saushev wrote:
>> Something like this?
>>
>> <<If you need [want?] to keep several package versions in pkgsrc then
>> "category/pkgname" (without suffixes) should point to latest stable
>> version of software other versions being alternative (older versions
>> or development versions). In the latter case package name should [may?]
>> get version suffix.>>
>
> My suggestion: You either have one package for one version of
> the software, or you have N+1 packages for N versions of the
> software.
>
> 1. If there is only one version of some software in pkgsrc, the
> the pkgsrc directory name and package name should be the
> base name of the software, without an embedded version number.
>
> 2. If there is more than one version of some software in
> pkgsrc, then:
>
> 2.1. The pkgsrc directory name and package name for each
> version should contain an embedded version number
> (e.g. "python26" and "python27").
>
> 2.2. At the discretion of the maintainer, the multiple
> versions may conflict with each other, or may be able to
> coexist.
>
> 2.3. There should also be an additional package without an
> embedded version number (e.g. "python"), which depends
> on the latest stable or recommended version of the
> software. At the discretion of the maintainer, there
> may also be a variable to adjust which version appears
> in the dependency. For example, "python" could depend
> on "python26" or "python27" according to the value of
> PYTHON_VERSION_DEFAULT.
>
> 2.4. If appropriate, the package without an embedded
> version number should provide wrappers or symlinks
> to make it easy for users to run the software. Such
> wrappers or symlinks are likely to be appropriate when
> multiple versions can coexist, and are not likely to be
> appropriate when multiple versions conflict with each
> other. For example, the "python" package could provide a
> symlink for PREFIX/bin/python to the version selected by
> PYTHON_VERSION_DEFAULT.
That sounds entirely reasonable, as long as people can choose to avoid
the python package with its attendant variable-binding problems, if they
favor reliability over convenience.
A nit is that sometimes we have 1 version, and then 2, and then back to
1, and I don't want us renaming back and forth. So once we go to two,
if we move to one we should stay with versioned names for perhaps 3
years before renaming.
Overall, this would be a policy shift from how emacs is named, but I
wouldn't mind it happening.