Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?

Matthieu Volat mazhe at alkumuna.eu
Sun Jun 8 11:42:02 UTC 2014


On Sun, 8 Jun 2014 00:16:18 +0400
Lev Serebryakov <lev at FreeBSD.org> 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 <lev at 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 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 <mazhe at alkumuna.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140608/1c7eeaf2/attachment.sig>


More information about the freebsd-ports mailing list