From owner-freebsd-ports@freebsd.org Wed Sep 27 20:57:38 2017 Return-Path: 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 C1FF2E0F0CC for ; Wed, 27 Sep 2017 20:57:38 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 83B0C1896; Wed, 27 Sep 2017 20:57:38 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v8RKvTem010871; Wed, 27 Sep 2017 13:57:33 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201709272057.v8RKvTem010871@gw.catspoiler.org> Date: Wed, 27 Sep 2017 13:57:29 -0700 (PDT) From: Don Lewis Subject: Re: [HEADUP] FLAVORS landing. To: julian@freebsd.org cc: matthew@FreeBSD.org, freebsd-ports@freebsd.org In-Reply-To: <91d1252c-5398-dca8-f337-959fa722efc7@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 20:57:38 -0000 On 27 Sep, Julian Elischer wrote: > On 27/9/17 4:20 pm, Matthew Seaman wrote: > > Before this gets too far down the road I would like to suggest that we > quickly formalise some nomenclature > or we will have 200 different ideas as to how to do the same thing; > > I would like to propose the following possible "examples of official" > flavours: > -nodocs   Â      ..  nearly every port has a DOCS option..  a way to > automatically turn it off globally and generate said pkgs would be good. > -minimal ..  smallest possible feature set.. probably used just to > satisfy some stupid dependency. > -kitchensink    ..  speaks for itself .. options lit up like a > christmas tree > -runtime        ..  no .a files, include files, development > documentation or sources .. >           Â          might only contain a single libxx.so.N file, or a > single binary executable. The docs and runtime would fall into the subpackages category along with things like debug symbols. For example, if you want to build a runtime package for port X, and X has a LIB_DEPENDS that points to Y, then you need to build a version of Y that contains both the shared library and the include files so that you can build X. Since you don't want to install the include files for Y when you install X, you would have to build another flavor of Y that doesn't have the include files. If you use subpackages, you would only need to build Y once, that that would generate subpackages for the runtime bits, the include files, the docs, and the debug files. If you use something like synth or poudriere for building X, it would install the runtime and include file subpackages of Y when building X. When you want to "pkg install" the X runtime, pkg would only download and install the Y runtime package. If at some point you run into a bug and need the debug files, you can pkg install the debug files for whatever packages that you need without disturbing your already installed runtime files, and then you can later deinstall the debug files when you are done with them without needing to reinstall the runtime files. The same thing applies to docs.