Date: Thu, 22 Dec 2016 12:46:29 -0700 (MST) From: Warren Block <wblock@wonkity.com> To: =?ISO-8859-15?Q?Ren=E9_Ladan?= <rene@freebsd.org> Cc: freebsd ports <freebsd-ports@freebsd.org>, freebsd-ports-announce@freebsd.org Subject: Re: Welcome to our new portmgr members Message-ID: <alpine.BSF.2.20.1612221245460.55196@wonkity.com> In-Reply-To: <04e44946-d458-85cf-4167-b7a23ff1ef44@freebsd.org> References: <04e44946-d458-85cf-4167-b7a23ff1ef44@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 22 Dec 2016, René Ladan wrote: > Hello, > > last week the Ports Management Team (portmgr) gained two new members: > Adam Weinberger (adamw@) and Mark Felder (feld@). Both have been a ports > committer for many years and Mark is also quite active on the Ports > Security Team. > > Yours truly has also been promoted to a full member. > > Please join me in welcoming Adam and Mark. Congratulations to them and you! From owner-freebsd-ports@freebsd.org Thu Dec 22 20:04:55 2016 Return-Path: <owner-freebsd-ports@freebsd.org> Delivered-To: freebsd-ports@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 AA083C8DD98 for <freebsd-ports@mailman.ysv.freebsd.org>; Thu, 22 Dec 2016 20:04:55 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wj0-x236.google.com (mail-wj0-x236.google.com [IPv6:2a00:1450:400c:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BD319D for <freebsd-ports@freebsd.org>; Thu, 22 Dec 2016 20:04:55 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wj0-x236.google.com with SMTP id c11so31740878wjx.3 for <freebsd-ports@freebsd.org>; Thu, 22 Dec 2016 12:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=vv1Qgsv18QsW78Q078QVqZFyqj5onTAdJpynaqZBkFU=; b=edg1MjoWV8kQ7mSmNd1r5RahAoivZEnHzyOY18F1vPVF0m9b1OkkkLl7foot5zzmU6 GlF7DgHlrptBoIwfC7OTbybpyzuFQNfCQJVFCyG16dOP78UYvwiyFXCSJbIhGT76T7+L Mslk9hAjGD/DiXIaQoyFSammClHcw9vr5g1JYYMSGF9nfGBb8+E4TQAMJTAsa3amhQ+3 ey8raEF2hmYlR2kToc5UauhrOoRJ/1btwtDBmoeJ/p6QKnQaxf/2Oi5NGLRGgobjj6Kn PRUCqsD99Pz+oauLxfikm57hfAOXS5nsql5ShL93L+XEI8/DUbb2ugjsmpd17zP5IXsN vFXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=vv1Qgsv18QsW78Q078QVqZFyqj5onTAdJpynaqZBkFU=; b=fdPpyq5r8mDE5a+hdzzrcA5E2vvAuf+bpNW0AoQYE7RJ7FebikIfsqN2EzOH4xLgMi fBHOydM+vzWuijQqDZRDrNADMBZmERBQQ7akLxGoXYY4E0zgUGBpFhWwVQ6o7QhuMbEI tlmRnunFlta/9t3BF4Dvo03cmG9KQmtmaUGNiwrtM789ndJvAGzl9TEj2J4HXMzSlobr G2YbWb7uCh/uRFPV8fDQfM+xJKa6VyXp5eX/MsH5bwyCOqAk4PKJEi17LOhKzmGG6XqO vXANvOro5vsRxIDN2kh+iT8z6wZNyIbrATQIYtaSjVKDUSL/GJ+W2HNwdbJ2eswqMfeA AFMQ== X-Gm-Message-State: AIkVDXIckKrotrO3gUnX0hXcJ1tTEqLXzylNWjiGju7U8/gXWHk9FvH3kI3giAV6j0NlgQ== X-Received: by 10.194.37.6 with SMTP id u6mr11679375wjj.20.1482437093376; Thu, 22 Dec 2016 12:04:53 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id b3sm37212641wjy.40.2016.12.22.12.04.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Dec 2016 12:04:52 -0800 (PST) Sender: Baptiste Daroussin <baptiste.daroussin@gmail.com> Date: Thu, 22 Dec 2016 21:04:52 +0100 From: Baptiste Daroussin <bapt@freebsd.org> To: Dewayne Geraghty <dewaynegeraghty@gmail.com> Cc: ports-list freebsd <freebsd-ports@freebsd.org> Subject: Re: HEADSUP: FLAVORS (initial version) and subpackages proposals Message-ID: <20161222200452.nzmkyw3rcydwaza5@ivaldir.etoilebsd.net> References: <20161219003143.c2qo5wn3a5kiua3m@ivaldir.etoilebsd.net> <58725f6d-aa60-3a62-7539-56e51e3cd76e@m5p.com> <8bc4754a-7200-b91d-8435-c6ff1970b56b@FreeBSD.org> <CAGnMC6pzH-xXinb3y1wjSXQ5aExvcts5KMiv0VUaCaug-+4Pxg@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7fxidraelvapuilc" Content-Disposition: inline In-Reply-To: <CAGnMC6pzH-xXinb3y1wjSXQ5aExvcts5KMiv0VUaCaug-+4Pxg@mail.gmail.com> User-Agent: NeoMutt/20161126 (1.7.1) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD <freebsd-ports.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ports>, <mailto:freebsd-ports-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ports/>; List-Post: <mailto:freebsd-ports@freebsd.org> List-Help: <mailto:freebsd-ports-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ports>, <mailto:freebsd-ports-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 22 Dec 2016 20:04:55 -0000 --7fxidraelvapuilc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2016 at 07:11:11PM +1100, Dewayne Geraghty wrote: > Thanks Bapt et al, >=20 > I use FreeBSD and the ports system extensively, we build everything from > source and largely customise approx 25% of the 900 packages we rely upon. > I'm more than a little concerned to have changes performed against the > ports infrastructure. As our primary sources of (whats coming) "Change" > information are the: Quarterly reports and the OS Release Notes; > after-the-fact sources are a daily review of > https://lists.freebsd.org/pipermail/svn-src-stable-11/2016-December/threa= d.html > for OS impact; and the excellent Freshports. >=20 > So a few questions: >=20 > Could you be able to enlighten us (the readers) so we can better understa= nd > what will be changed; or share your vision of the benefits and operational > impact for operational people that build: from source; and those that only > use binary? Sure so there are 2 different things that are requested for a long time by = lots of users: 1/ flavors This is the avility to say this port should be built with a list of variations by default. There are 2 kind of flavors: a/ the one that are not conflicting: for example being able to have all pyt= hon ports available for both python 2 and python 3 by default and at the same time. Right now it is not directly possible without a hack b/ the one that makes variations of a given package right now done a hackis= h way via the (for example) *-nox11, *-static or *-lite. The goal of the change I do propose aims at making both kind of flavors eas= ily maintainable. The difficulty is bringing in that feature without breaking anything for end users. The clean way would be to to just have a new variable in a given port that describes the possible variations. But that would break all existing extern= al tools that deals with the ports tree. Because they all rely on the fact that there is a mapping between a package name and an origin (not that pkg does = not rely on that. It means that for poudriere and synth we can easily adapt them, both are ve= ry actively maintained and their design should allow "easily" to integrate that But portmaster and portupgrade would be deeply broken as not actively maintained So I decided to go another way: add a third level to the ports tree. So far= we have category/port and I do propose to add a third level: category/port/fla= vor which will keep the paradigm most tools are expected: 1 packagename =3D=3D = 1 origin Maybe some tools would have to be updated a bit, but that would be minor pa= tches With my current patch the only problem I see that the category/port level is unused if there are flavors while I could certainly make it "the default fl= avor" the drawback of this approach is it will add a lots of new small files and directory. The most important part of the flavors is probably the ability to provide natively support for python2 and python3 at the same time A good side effect of adding a third level is we could now imagine regroupi= ng some ports (the openbsd ports tree does that already) like aspell where we = could have: textproc/aspell and textproc/aspell/fr textproc/aspell/en etc which would m= ake things a bit cleaner 2/ sub packages sub packages is the ability from one build to create multiple packages. The goal is to avoid the giant gcc package as a runtime dependency for exam= ple where we could provide a gcc-libs package for the runtime libary It would also allow to save a lot of building time for things like php or q= t We could end up with on single port (so one single extraction and one single r= un of the configure script) while keeping the flexbility of the current split whi= ch is existing right now in the ports tree with zillion of complex slave ports. The big issue while designing that solution is it cannot be made transparen= t for the users as it will for sure break the paradigm: 1 pkgname =3D=3D 1 origin >=20 > Is there a transition plan or schedule for the bulk of these changes to > occur? For flavours it should be transparent if not that would be a bug except if everyone argue I should break the paradigm 1 pkgname =3D=3D 1 origin and go= for the clean implementation >=20 > Will the flavors/subpackages be developed separately from the existing > ports suite? (I'm hoping that the parent ports will be unaffected, and so > our existing build procedures continue to build correctly) I don't see how it can be developped separately, can you elaborate more? >=20 > How will we (the users/admins) track or be informed of changes or better, > planned/soon changes? (will changes to ports, particularly parent ports, > be co-ordinated through UPDATING or perhaps a new FLAVOURS file if the > parent is say a stub and the real decisions are relocated to slaves?) Yes of course UPDATING and MOVED when needed for example shells/bash-static|shells/bash/static|.... >=20 > Will there be any guidance regarding how flavours/packages should be > created or the criteria for creating sub-packages (secure/insecure; all > options on/off; most useable options on; most liked by the maintainer; mo= st > likely to be used for a datacentre; most likely to be used for desktops; > ...)? Will "The Porter's Handbook" be updated for things like criteria; > naming conventions etc? There won't me less or more guidance than nowaday. I'm not in portmgr anymo= re so maybe portmgr will decide differently :) >=20 > For folks (like me) that build entirely from source and customise options > to build the applications, how will flavours/subpackages be of benefit? > Will the ability to customise ports, as they exist today, remain? Will I > even notice a change? flavours and subpackages will be a benefit because it will reduce the requirement to have OPTIONS (for some case) meaning you will have less work= to get the same level of flexibility you having now (probably even more) For non source builder they will benefit more flexibility than they have no= w. >=20 > I'd like to plan ahead to make this transition seemless and continue to u= se > FreeBSD and the excellent ports system as we do now. As far as I remember I have always worked hard on making the majors changes= I brought in the ports tree as seemless as possible for users (the replacemen= t of the option framework for example, the complete rewrite of how LIB_DEPENDS is handled). I will do the same for those features even if that sounds very ha= rd to achieve for subpackages for now. >=20 > I started with FreeBSD 2.2.8. There were packages available from the > FreeBSD website. It was a terrific aid. We also enjoyed the different > flavours of jail that were provided by ezjail. However over time, both > evolved as did our expertise to customise our ports (~200 custom ports) a= nd > Jamie Gratton evolved the jail system to eliminate our need of the > excellent ezjail tool. So I can see merit in, what very little I'm > guessing of, the next evolution of ports. >=20 > Aside: we already build different package configurations from existing > ports' source. (eg different bind910 with/without kerberos; different > samba44's; simultaineous building of dhcp-[server|client|relay] etc) >=20 > I look forward to being on the same page and to understand where this is > going, the likely/potential impact; the naming conventions; etc. I hope I anwered properly to your expectations, if not please to not hesita= te to ask more :) Best regards, Bapt --7fxidraelvapuilc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlhcMdkACgkQY4mL3PG3 PlqMNhAAig4BcndJBTAgDndqrLNNh8B8G4V7ZgVdqj4YkgNXukz1lMah5EDtAMBI bQoEb8W2j/RbYDRPo38KJutEfQ0kBECMTDvQtMpvWAefYzLCB8e/6fKxYrUe63dO Qxh63tWqm+NUbNURIrYyh6z111LADAXBuDu4G/IewnwcNi54C4sQwvdTUSZ8pcoh 2UoK7mdt/kVRikwO+PuXvjZuCzDNTVoyTA+uDoVkSBPs3x5Ys7h4SGFO2S4xQXA7 LTdsRVjQPYBs7j4iNUhnYvuGXobycuqmHpqxp4R9G6lJsLPTNzP5Eshnkr1dZ9q3 UteXp40wmTmB3QznPynp+1jnV024aOhFn6TCpamyZKWaznNbc4F6rommu5PSp/Pf BaAsUVFtdji5WLThfgdOAaR3HGJS4FHmdhpoDanJPLGdflcIiPd/qOliMCQhIXIQ OHU5LDBdfxCX+DnXBfbz+50XYp9eclOWFV+HHYNoeKQUMS4PoHqIJlLMKx+c83/k NYrpnoNtQMjp/yPum+ZijNBPW3daK4qN7eF/GXzH2hDrOGXcyZ6USpaT5kFIgMCt 1KiAQvccn52ZEtnytydLtnBb+TDmOKgXJM8vltnVhJ4aOXYKOzojTAKcL6EJ+UQa X1xvTv4aFA+zw5Qhpy3lmxbUDFTVwaW9OCQo4zG9cLhl7P1mogU= =jJEj -----END PGP SIGNATURE----- --7fxidraelvapuilc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1612221245460.55196>