On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon <a...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
