From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 17:59:19 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C82AB106566C; Mon, 28 Mar 2011 17:59:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D8DDD8FC1A; Mon, 28 Mar 2011 17:59:18 +0000 (UTC) Received: by wyf23 with SMTP id 23so3614451wyf.13 for ; Mon, 28 Mar 2011 10:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=60OnWn0HjweAirr4pnE/xbyGjooXV91MZuYEWHTZg3s=; b=uHQnRNy2n/PG1K4mKPAXRU6wWcrDNBzmUvtpJBwF7oH+f4Ms4s7jyziPPggQf1dgbO 6Wu+IftsRC8a4Vp8jE4sI3bfYAech2SYPHNT7GsZvBoqgXoKTPPpAbSncDKbChuZNNYJ xbaQMJOyHiOu+Ob8N8xbFQpiqnz1f0C//4emM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=h7Wrb9m0b56SQkC4mVUA2Kunp6GPFePyiF3LMk9716O9oKJfjsdF1iZjyfpuYZWjJH T4KyF7PvfJbgkA+MmL2Slg6MCTyhKUBYLrXRPSMw9Q813i0DhqGiWiuWzz8uXFgjX+Ay cARcufbiLP1qx4OBmzLJ/WCCi/DvobN3O2WEc= MIME-Version: 1.0 Received: by 10.217.7.66 with SMTP id z44mr3676901wes.100.1301335157735; Mon, 28 Mar 2011 10:59:17 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.173.142 with HTTP; Mon, 28 Mar 2011 10:59:17 -0700 (PDT) In-Reply-To: <4D90C8EA.2000901@freebsd.org> References: <20110325101111.GA36840__48943.3474642739$1301049771$gmane$org@azathoth.lan> <4D90C8EA.2000901@freebsd.org> Date: Mon, 28 Mar 2011 10:59:17 -0700 X-Google-Sender-Auth: uG7d0O3NGdtpDgicYCvc80felmY Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org, Baptiste Daroussin , hackers@freebsd.org Subject: Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:59:19 -0000 On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon 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