[ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

[Andriy Gapon]

on 25/03/2011 12:11 Baptiste Daroussin said the following:
> Hi all,
> 
> miwi@ launched the new thing called Experimental Call For Testing,
> it's our turn :)
> 
> Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge
> contributor) have been working since the end of the last GSoC on a
> rewrite of pkg_install.
> 
> pkgng is a binary package manager written from scratch for FreeBSD.
> 
> After a long period of technology testing, (json, tinycdb, bdb, etc)
> and we now have achieved to implement the basic functionnality. We
> would greatly approciate to have some feedback, wider testing,
> patching, documenting etc, before implementing the higher level
> features.
> 
> pkgng is built on top of a new libpkg, which allow to deal with the database of
> installed packages, to deal with remote repositories, manage packages:
> creation, installation gathering informations, registering new ports.
> 
> features supported are or will be :
> 
> - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486)
> which allow  to have a bsd.port.mk which deal with both pkg_install
> and pkgng. (done in alpha)
> 
> - the register command can analyse elf files when registering a new port to
> discover forgotten dependencies if necessary. (done in alpha using libelf)
> 
> - the register command has two mode available : when dealing with old
> fashion ports it just registers the package, in new mode it does
> everything that would
> have been done by pkg add when installing the package : should display
> messages,  execute post-install, execute @exec etc. (old fashion done
> in the alpha)
> 
> - pkg add supports two mode : the old fashion one (no real upgrade
> support) and  new one: upgrade scripts supported. (old fashion in the
> alpha)
> 
> - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL,
> +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion
> scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't
> supported in the alpha)
> 
> - new +MANIFEST (plist-like format) with new metadatas : options, arch, os
> version, etc. (done in the alpha)
> 
> - pkgng supports checking arch of the package which means that users
> won't be able to install sparc64 binary package into amd64 machines.
> (not done yet)
> 
> - a special architecture "all" allows to specify when a package can be used
> on every architecture. (not done yet)
> 
> - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself
> which directory has to be removed. (done in the alpha but needs love
> :))
> 
> - new repository (apt-like feature) (only the repository generation is done)
> 
> - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the alpha)
> 
> - test unit (libcheck) on libpkg. (done in the alpha needs some more love)
> 
> - many more

Perhaps I am too impatient :) but I would like to inquire about the following
features:

I. A provides/requires interface for packages.
Each package specified a list of files (and perhaps other entities) that it
provides and requires.  At the initial stage, without ports modifications, these
could be: (1) a list of all files installed by package for provides; (2) for
requires - an auto-generated list of dependencies based on required shared
libraries plus dependency specifications in ports.
I think that this kind of interface should help with using alternatives that
provide the same interface (e.g. like gamin vs fam).

II. Package signing.

III. Package naming that includes architecture, major OS version (for API/ABI),
maybe more.

IV. "Convenient" support for i386 packages on amd64.
Distinct installation directories, proper installation conflict
detection/avoidance between i386 and amd64 packages, proper library paths, etc.

And finally some exotic ideas - support for multiple package sources (when
different people build packages in different ways (e.g. with different options, or
different optimizations) from the same ports tree; support for multiple ports
sources.(when people maintain different ports tree (e.g. kde or gnome development
ports tree)).  Perhaps, with some compatibility/hierarchy support for packages and
ports sources.  But that's almost a pipe dream, so don't take it seriously :)

-- 
Andriy Gapon