On Sun, 8 Jun 2014 00:16:18 +0400 Lev Serebryakov <[email protected]> wrote:
> Hello, Ports.
>
> 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:
>
> (1) devel/subversion-libs -- base libs, used by all other ports. Options
> 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, like
> patches and all infrastructure).
>
> But it is possible to extract more options to separate ports: BDB repository
> 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?
>
> --
> // Black Lion AKA Lev Serebryakov <[email protected]>
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
headers.
An aspect of ports I liked was it followed/respected the upstream packaging
mindset, instead of going for artificial repackaging like linux distros. This
minigame of cutting other people works in tiny atomics bits so I have to 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 where
binary is prefered).
Be more like macports, less like apt.
My 2 cents.
--
Matthieu Volat <[email protected]>
signature.asc
Description: PGP signature
