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

[Garrett Cooper]

On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon <avg at freebsd.org> wrote:
> 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.

That would be really nice.

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

This could be provided in the manifest. Doing it in the filename sort
of turns into a mess, as I've discovered working at Cisco :).

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

There are other architectures that would benefit from this as well,
like powerpc 32-bit on 64-bit, MIPs 32-bit on n32, etc.

This involves more work than pkgng could provide IIRC as build
infrastructure would need to be fixed to look at and link against
usr/lib32 instead of usr/lib, unless you mean to rewrite the linker
stuff at install-time.

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

It would be nice. That's a request in the same general area that
Gentoo portage's overlay goes into, but I think that would require
rewriting certain bits of ports infrastructure to be extensible, not
extend pkgng in this area.

Thanks,
-Garrett