[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
same name different package (was Re: package repo sanity checking)
On Sat, 26 May 2012, Aleksey Cheusov wrote:
> emacs (from 5 PKGPATHs)
> emacs-20.7nb14 editors/emacs20
> emacs-21.4anb22 editors/emacs21
> emacs-22.3nb17 editors/emacs22
> emacs-23.4nb1 editors/emacs
> emacs-126.96.36.19920319 editors/emacs-snapshot
> I don't know how pkgin works here, but nih identifies packages using
> (PKGPATH,PKGBASE) pair.
> That is, if emacs is not installed yet, "nih install emacs" installs
> the highest available version (24.0.94) . On the other hand, if
> emacs-22, for example, was already installed
> from editors/emacs22, other emacses will never be candidates for installation.
> Manual upgrade is possible: "nih install emacs- editors/emacs23".
> This this replace emacs with editors/emacs23. That is PKGPATH of
> installed packages will never change
> automatically. This is a feature. Uploaded pkg_summary are correct.
As this point brings us back to
"Re: multiple version of packages with the same PKGBASE"
"Re: Apache packages"
and other threads.
Again let us make it as easier for end-users.
If a user wants to install "emacs" (just that), is it correct for them
to get the package known as a "snapshot"? That doesn't sound like a
I propose that generically we always do:
emacs20 (or emacs2.0) editors/emacs20 or (editors/emacs2.0)
emacs21 (or emacs2.1) editors/emacs21 (or editors/emacs2.1)
emacs22 (or emacs2.2) editors/emacs22 (or editors/emacs2.2)
emacs23 (or emacs2.3) editors/emacs (or editors/emacs2.3)
As for "snapshot" I don't know. Either:
emacs-snapshot or emacs24 or emacs-2.4 (and directory name matching)
and clearly marked in comment line and description as experimental
(I don't use emacs and so I may not be correct and maybe should use
apache as an example instead.)
Then finally a metapackage simply known as "emacs" that pulls in the
latest best version decided by the emacs maintainers. The version can
match the dependency major version and always use PKGREVISION for
package changes so won't be confusing. For example foo-2nb3 could depend
I understand that as this dependency changes the usability and
configurations may significantly change, so the maintainer(s) of the
versions could simply decide to have no meta-package and document their
It is fine to have many choices, but I think we can make it easier.
(By the way, I looked at a Debian system with tens of thousands of
packages; I think the only duplicate names were choices of installing
amd64 versus i386 build of same version.)
Main Index |
Thread Index |