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. > > 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 the > 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 over.
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 away.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
