Date: Sun, 8 Jun 2014 13:41:42 +0200 From: Matthieu Volat <mazhe@alkumuna.eu> To: Lev Serebryakov <lev@FreeBSD.org> Cc: ports@FreeBSD.org Subject: Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it? Message-ID: <20140608134142.4d4a0ae1@freedom.alkumuna.eu> In-Reply-To: <1438330868.20140608001618@serebryakov.spb.ru> References: <1438330868.20140608001618@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/c1uxkOVr.EDxATSuB/7nsNP
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Sun, 8 Jun 2014 00:16:18 +0400
Lev Serebryakov <lev@FreeBSD.org> wrote:
> Hello, Ports.
>=20
> I've learned proper way to split subversion into several ports. Question
> is: how fine-grained should I do this? I want to split it at least into:
>=20
> (1) devel/subversion-libs -- base libs, used by all other ports. Optio=
ns
> about SERF, BDB and SASL goes here.
> (2) devel/subversion-client -- all base tools, like "svn", "svnversion" =
and
> so on, but not "svnserve".
> (3) devel/subversion-server -- svnserve binary.
> (4) devel/subversion-tools -- additional tools (option now).
> (5) devel/subversion-apache -- all mod_dav_svn-related stuff.
> (6) devel/subversion-gnome -- GNOME KEyRing integration (option now).
> (7) devel/subversion-kde -- KDE KWallet integration (option now).
> (8) devel/subversion -- meta-port with options (and real stuff, l=
ike
> patches and all infrastructure).
>=20
> But it is possible to extract more options to separate ports: BDB reposit=
ory
> format, remote access with "svn:" scheme and SERF support ("http:" scheme
> remote access) could be separate ports (and packages), not options! But
> maybe, it is "too much" already?
>=20
> --=20
> // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
Holy...
Is this Debian now? How about 14 packages to have granularity over what sub=
-library needed, and 23 others for each svn* command? And don't forget head=
ers.
An aspect of ports I liked was it followed/respected the upstream packaging=
mindset, instead of going for artificial repackaging like linux distros. T=
his minigame of cutting other people works in tiny atomics bits so I have t=
o figure what is missing at runtime is tiresome.
If this is a binary/options issue, I'd rather see an effort in providing a =
system able to allow using globally packages with local build when desired =
options differs, and the reverse (build everything except a list of stuff w=
here binary is prefered).
Be more like macports, less like apt.
My 2 cents.
--=20
Matthieu Volat <mazhe@alkumuna.eu>
--Sig_/c1uxkOVr.EDxATSuB/7nsNP
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlOUS/4ACgkQ+ENDeYKZi361fwCglR5aAf39u7hfyeBye0saLzEv
KeYAn3IHvmh65U43D8K2Ahdqs8/GaPIO
=diQ+
-----END PGP SIGNATURE-----
--Sig_/c1uxkOVr.EDxATSuB/7nsNP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140608134142.4d4a0ae1>