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 _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
