From owner-freebsd-pkgbase@freebsd.org Sat Jan 30 09:10:04 2016 Return-Path: Delivered-To: freebsd-pkgbase@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1FA1A72EEC for ; Sat, 30 Jan 2016 09:10:04 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 836541A07; Sat, 30 Jan 2016 09:10:04 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aPRXc-000BA2-Ox; Sat, 30 Jan 2016 12:10:00 +0300 Date: Sat, 30 Jan 2016 12:10:00 +0300 From: Slawa Olhovchenkov To: Glen Barber Cc: freebsd-pkgbase@FreeBSD.org Subject: Re: TODO/wish list for packaging the FreeBSD base system Message-ID: <20160130091000.GL88527@zxy.spb.ru> References: <20160129173506.GG1727@FreeBSD.org> <20160130021539.GM1727@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160130021539.GM1727@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-pkgbase@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Packaging the FreeBSD base system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 09:10:04 -0000 On Sat, Jan 30, 2016 at 02:15:39AM +0000, Glen Barber wrote: > [Note, I did see Garrett's email. Garrett, I'll reply to your questions > but following up on one specific point in this list.] > > On Fri, Jan 29, 2016 at 05:35:06PM +0000, Glen Barber wrote: > > TODO List / Wish List: > > > > [...] > > > > - Unless there is a specific reason to have an in-tree .ucl > > file in src/release/packages/, I would like to see a template used > > instead. Use cases where an in-tree .ucl file is needed are > > runtime.ucl and kernel.ucl, where post-install scripts are defined. > > For the rest of the currently-existing package definitions, it is not > > necessary, and adds to the complexity of breaking down the base system > > into more granular package sets. I tried a few tests yesterday using > > a file called '_template_.ucl', which if the release/packages/foo.ucl > > did not exist, the '_template_.ucl' file would be copied to the stage > > directory. This did not work, however, because there can be several > > '.ucl' files for any given 'package', notably runtime.plist, > > debug.plist (which should be runtime-debug.plist), runtime-lib32.plist > > and so on. > > It occurred to me that there is a use case for in-tree .ucl > files, specifically when an update is necessary. The package versions > come from the PKG_VERSION make(1) environment, and if not set, will > default to the epoch timestamp. This was a design decision that was put > in place to handle SAs/ENs, where we could trivially bump the package > version. Specifically, for an SA/EN, a commit to the tree that would > trigger a rebuild of an affected package would look similar to this: How this will interaction with customs builds/rebuild/packaging with or w/o source updating? > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Index: release/packages/rcmds.ucl > =================================================================== > --- release/packages/rcmds.ucl (revision 295058) > +++ release/packages/rcmds.ucl (working copy) > @@ -1,6 +1,6 @@ > name = "FreeBSD-%PKGNAME%" > origin = "base" > -version = "%VERSION%" > +version = "%VERSION%,1" > comment = "Remote Command Tools" > categories = [ base ] > maintainer = "re@FreeBSD.org" > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > So, while I do not necessarily like relying on in-tree .ucl > files, as right now it makes it difficult to package components not > "normally" included in the base system, I now remember the necessity of > this. > > It might be a better idea to add a TAGS or PACKAGE_VERSION value to the > relevant makefiles, which could be included in the mtree(8) tag when > creating the METALOG files. > > Glen >