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

[Julien Laffaye]

On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper <gcooper at freebsd.org> wrote:
> 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).

Adding require/provide support in pkgng is kind of trivial. But ports
have to support it first.

>>
>> II. Package signing.
>
> That would be really nice.

Right know we only planned to sign the repo database, so we can trust
the sah256 of the packages stored in the database. Then if the package
has the same sha256 as the one in the repo database it is considered
trusted.
If we want a per-package signing, we would have a tarball in a tarball.

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

Actually, it *is* in the +MANIFEST of pkgng packages archives :-)

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

I dont think we are going that way right now...

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

Well, I think we are doing the basics first. We will see later.
BTW, the +MANIFEST file contains the options a package was built with.

>
> Thanks,
> -Garrett
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>