tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: package repo sanity checking

On Sat, 26 May 2012, Aleksey Cheusov wrote:

> 1)
> amule (from 1 PKGPATHs)
>  amule-2.2.6nb8 net/amule
>  amule-2.2.6nb9 net/amule
> I don't know about pkgin, but "nih install amule" automatically selects
> the highest available version of the package for installation, i.e. 2.2.6nb9.
> Also, you can manually select another version, i.e, "nih install
> amule-2.2.6nb8".
> So, I don't see problems here. pkg_summary is correct.

At first I thought it was confusing or a waste to continue to host and 
mirror old packages.  But now I realize that some may not have updated 
pkg_summary so will retrieve the old versions. This may or may not be 
okay. If missing, this could just encourage them to retrieve a new 
pkg_summary (tool could hint about this). Or we could let them use old 

I was wondering if we should have a schedule to purge, but realize that 
the 3 month lifetime of a branch is good enough. It is probably fine to 
keep the old packages available.

But I don't understand the purpose of keeping them listed in the 
pkg_summary file?  Yes I understand it may make it easier to install old 
version.  But this polutes the output of available packages. pkgin lists 
all the choices; now the end-user pauses to think about it: "Why version 
2.2.6nb9 and 2.2.6nb8 both available?" Well same version but maybe some 
difference and some good reason that the old one is still there. Even 
the default "search" or "avail" output doesn't tell you the PKGPATH so 
you can't know if is same package or not. (This is bad example since 
2.2.6 and 2.2.6 are same; ignore that point.)

pkgin does default to install the latest version. But still confusing to 
show many duplicates. My goal is to make end-user experience as easy as 

Should we continue to host old packages (now have new versions in same 
repo) for life of the branch?

Should we continue to list old packages in pkg_summary?

Is there a good reason that an end-user would want to purposely install 
an old version? (And will we support the fallout from that?)

(I don't know behaviour if user chooses old version and then does an 
upgrade immediately; I guess it does not define pinning and will upgrade 

Home | Main Index | Thread Index | Old Index