Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 08 Feb 2014 10:29:04 +0000
From:      Matthew Seaman <matthew@FreeBSD.org>
To:        marino@freebsd.org, lev@FreeBSD.org
Cc:        ports@freebsd.org, Dimitry Andric <dim@FreeBSD.org>
Subject:   Re: USE_GCC politic -- why so many ports has it as runtime dependency?
Message-ID:  <52F606F0.5090605@FreeBSD.org>
In-Reply-To: <52F5FAD3.8090001@marino.st>
References:  <1133138786.20140207202949@serebryakov.spb.ru> <A136680D-BD8A-4819-9600-6B640AB16ADE@FreeBSD.org> <1228142552.20140208033432@serebryakov.spb.ru> <52F56EB9.4010700@marino.st> <1955647943.20140208122042@serebryakov.spb.ru> <52F5EB97.5040603@marino.st> <686179459.20140208132425@serebryakov.spb.ru> <52F5FAD3.8090001@marino.st>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--q0n2mrvUVOlsnwKuLpo07k95kxOUXWC6g
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 08/02/2014 09:37, John Marino wrote:
> Your "solution" causes multiple issues for others, and for what benefit=
?
>  The libraries are not packaged individually.  You would need to split
> up every GCC package into at least two packages, and then change the
> infrastructure to add the compiler as the build dependency and the
> libraries as a run dependency.  I do not see the library dependencies
> getting whittled down to 5 - 15 separate packages though.  That is way
> too much of a maintenance headache.
>=20
> But the fact that you don't use use specific libraries is irrelevant.
> The needs of the entire tree is what is being considered, as well as th=
e
> amount of work the maintainers are willing to do.  GCC x 5 is a set of
> monster packages that I don't see a bunch of people clamoring to take o=
ver.

In fact, this /is/ the plan.  This is exactly the sort of thing we want
to achieve by implementing sub-packages.  However, in the case of
dependencies on compiler toolchains, this shouldn't require massive
interventions in the ports tree.  If we create separate
gcc-c++11-runtime or clang-objc-runtime or whatever other combination
sub-packages, then it should be mostly a case of updating
/usr/ports/Mk/Uses/compiler.mk so that it registers a BUILD_DEPENDS on
the entire toolchain, and a RUN_DEPENDS on just the appropriate runtime
sub-package.

There are various other obvious sub-packaging chunks like separating out
documentation and examples, and various files that are now added to
packages due to options settings.  So it's going to be another sweeping
change across the ports, perhaps not quite so all-encompassing as the
current switch to staging, but similar.  (Staging is actually a
prerequisite to introducing sub-packages; the other requirement is
obsoleting the old pkg_tools, as they can't deal with this.)

Other than getting over the hump of implementing all this, will this
result in a massively increased workload for port maintainers?  It
shouldn't.  Essentially one port will now generate several sub-packages
instead of one package.  This will be automatic: just dividing up the
files from staging into different pkg tarballs according to tags given
in pkg-plist.  Tags which frequently already exist according to
OPTIONS_SUB.  It also means that in a lot of cases we will be compiling
all the different optional parts of a port regularly, so problems with
obscure parts should come to light more quickly.  Also the oft repeated
complaint that lang/php5 doesn't enable mod_php5 by default: that goes aw=
ay.

	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey



--q0n2mrvUVOlsnwKuLpo07k95kxOUXWC6g
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJS9gb4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC
QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATnjUP/0RlFDKbs0JcCSV0lTOqTqPu
vXfpDiNQES8h8pTLjAW+6YgmLQdGdzotghxowfNTV5zE29xyDSFjxFq8ILukvSP3
Z8zujaf5QOviIuVjWMq5xqfsI08tRlhUt//Fb7snIBBQOog+ldJMkTjoNMsZhjz6
U5S2t1rLjybZM86fnk0O1+ViwxAJdYo6rnZFdKRUdRiNveVIGEs+gPBXWJsDnWea
FZJAqvNWTLwkWiDnKFZLhIGaRq0i3kAKrkuXXEIlcFDnl9pC4m5m7Fo4ZsG/Iabb
+varftzHyw+clSjBEFX/hVgzfE1c6Z09zlhQvqG9LYoiNDbZ4+nA1GcMPdrbXTgv
6WAD02+30Z9e51+mvoof+h2mmS4z35B/DszUrl2hjv+xI3A3LC3vKnm2lfmAvuiY
GLW5xtbloATs4VecCTQfiTbHMXEC22vunlB/5iqSutYyyPf3LZC8VnYeDuIMD5ja
MUfD84V3HOP5gSmkY+QE8MWi6bTWBVTXG7VcSDjLC/g/rRts/D77NhCT6975BQAv
jhmgjvniCRywh/wE8Dg4K/nWvK1K9j0exNexkFlXDYCggcdOh2xZML9K/e/ZMTlK
4NtOAUXwsmpRDEtS/SPyozFa/aIyd4rQvlOgiGdpxv72jvNF3vuFQk9JHaP97KPj
miM1n2/Z020//Hp4pOku
=44ad
-----END PGP SIGNATURE-----

--q0n2mrvUVOlsnwKuLpo07k95kxOUXWC6g--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52F606F0.5090605>