tech-pkg archive

[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:

> 2)
> 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- editors/emacs-snapshot
> I don't know how pkgin works here, but nih identifies packages using
> 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 
vetted release.

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 
on foo2-2.9.99.

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.)

Home | Main Index | Thread Index | Old Index