Date: Mon, 28 Mar 2011 10:59:17 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: Andriy Gapon <avg@freebsd.org> Cc: ports@freebsd.org, Baptiste Daroussin <bapt@freebsd.org>, hackers@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install Message-ID: <AANLkTinaz9Y6kgjQvdS1Pu%2Bkay50DUs6FubcbCxcc3W2@mail.gmail.com> In-Reply-To: <4D90C8EA.2000901@freebsd.org> References: <20110325101111.GA36840__48943.3474642739$1301049771$gmane$org@azathoth.lan> <4D90C8EA.2000901@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon <avg@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 data= base 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 =A0to 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 libel= f) >> >> - 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, =A0execute 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 =A0new 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 u= sed >> 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 d= one) >> >> - real support for reverse dependency (no ugly +REQUIRED_BY) (done in th= e alpha) >> >> - test unit (libcheck) on libpkg. (done in the alpha needs some more lov= e) >> >> - many more > > Perhaps I am too impatient :) but I would like to inquire about the follo= wing > features: > > I. A provides/requires interface for packages. > Each package specified a list of files (and perhaps other entities) that = it > provides and requires. =A0At the initial stage, without ports modificatio= ns, 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 share= d > libraries plus dependency specifications in ports. > I think that this kind of interface should help with using alternatives t= hat > 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 (whe= n > different people build packages in different ways (e.g. with different op= tions, or > different optimizations) from the same ports tree; support for multiple p= orts > sources.(when people maintain different ports tree (e.g. kde or gnome dev= elopment > ports tree)). =A0Perhaps, with some compatibility/hierarchy support for p= ackages and > ports sources. =A0But that's almost a pipe dream, so don't take it seriou= sly :) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinaz9Y6kgjQvdS1Pu%2Bkay50DUs6FubcbCxcc3W2>