Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
On 2014-09-04 17:10, James R. Van Artsdalen wrote: So how does port subversion work now? I don't get mod_dav_svn installed and I don't see a knob for it. There is port www/mod_dav_svn but devel/subversion doesn't seem to reference it, and www/mod_dav_svn just gives errors when apache24 tries to start.(needs shared memory support that or some such). port devel/subversion does have the mod_dav_svn code in the work tree; it just isn't installed. Hi James, the port was separated, so devel/subversion can be installed via pkg from pre build packages without having apache as dependency. Unluckily in the first apache24 revision not all required modules where ON per default but this was fixed some weeks ago. In case you don't use custom apache24 options just run `make rmconfig make config' inside the www/apache24 port directory to pick up the new default module list. To compare the options before after run before 'make showconfig cfg.old' and after reconfigure the OPTIONS 'make showconfig cfg.new' To build the apache module install devel/subversion and then www/mod_dav_svn (there are pre build packages available, `pkg install devel/subversion www/mod_dav_svn') After installing apache24 compare your etc/apache24/httpd.conf with the httpd.conf from your new build (/usr/local/share/examples/apache24/httpd.conf) E.g vimdiff /usr/local/etc/apache24/httpd.conf /usr/local/share/examples/apache24/httpd.conf and merge missing LoadModule directives into existing etc/apache24/httpd.conf A possible configuration file candidate that will be used by the subversion port in the future can be found here (replace %%APACHEMODDIR%% with libexec/apache24) http://people.freebsd.org/~ohauer/diffs/220_subversion.conf.sample.in As soon as pkg support sub packages it is possible the port will change again since then it is no longer required to split the port into pices. -- hth. olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
So how does port subversion work now? I don't get mod_dav_svn installed and I don't see a knob for it. There is port www/mod_dav_svn but devel/subversion doesn't seem to reference it, and www/mod_dav_svn just gives errors when apache24 tries to start.(needs shared memory support that or some such). port devel/subversion does have the mod_dav_svn code in the work tree; it just isn't installed. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
On Sun, 8 Jun 2014 00:16:18 +0400 Lev Serebryakov 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? I don't want to stop you from doing this, but if I were you I'd just wait for subpackages support. You may want to merge all those ports back into one port then. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
On Sun, 8 Jun 2014 00:16:18 +0400 Lev Serebryakov l...@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 l...@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 ma...@alkumuna.eu signature.asc Description: PGP signature
Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
Hello, Tijl. You wrote 8 июня 2014 г., 14:16:14: TC I don't want to stop you from doing this, but if I were you I'd just TC wait for subpackages support. You may want to merge all those ports TC back into one port then. It is second way. But I didn't seen any estimations about subpackages support, and separate mod_dav_svn is request which I got twice a month. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
Hello, Matthieu. You wrote 8 июня 2014 г., 15:41:42: MV Holy... MV Is this Debian now? How about 14 packages to have granularity over what MV sub-library needed, and 23 others for each svn* command? And don't forget headers. MV An aspect of ports I liked was it followed/respected the upstream MV packaging mindset, instead of going for artificial repackaging like MV linux distros. This minigame of cutting other people works in tiny MV atomics bits so I have to figure what is missing at runtime is tiresome. MV If this is a binary/options issue, I'd rather see an effort in MV providing a system able to allow using globally packages with local MV build when desired options differs, and the reverse (build everything MV except a list of stuff where binary is prefered). With pkgng in play, I get more and more requests from people, who want to use only binary packages. And when such vital (for many) features as mod_dav_svn and (not so vital, but desirable) DE integration is non-default options of single port, it could not be done. BTW, nobody objects against separated language bindings, especially Java ones :) Really, I get requests to have mod_dav_svn package at least twice a month for all time subversion port exists. But, yes, maybe separation to libraries and binaries is too much, and I need only extract apache-related stuff and DE-related stuff. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
On Sun, 8 Jun 2014 16:27:15 +0400 Lev Serebryakov wrote: Hello, Tijl. You wrote 8 июня 2014 г., 14:16:14: TC I don't want to stop you from doing this, but if I were you I'd just TC wait for subpackages support. You may want to merge all those ports TC back into one port then. It is second way. But I didn't seen any estimations about subpackages support, and separate mod_dav_svn is request which I got twice a month. Yes, I have some questions about subpackages myself. For instance, will a port be able to depend on the subpackage of another port? Will the infrastructure be smart enough to build just that subpackage then or will it build the full package (and all of its dependencies) and then split up the stage directory? If a port has to smart then you may want to split subversion up now because you'll need all that logic for subpackages too. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
On Sun, Jun 08, 2014 at 02:41:21PM +0200, Tijl Coosemans wrote: On Sun, 8 Jun 2014 16:27:15 +0400 Lev Serebryakov wrote: Hello, Tijl. You wrote 8 июня 2014 г., 14:16:14: TC I don't want to stop you from doing this, but if I were you I'd just TC wait for subpackages support. You may want to merge all those ports TC back into one port then. It is second way. But I didn't seen any estimations about subpackages support, and separate mod_dav_svn is request which I got twice a month. Yes, I have some questions about subpackages myself. For instance, will a port be able to depend on the subpackage of another port? Will the infrastructure be smart enough to build just that subpackage then or will it build the full package (and all of its dependencies) and then split up the stage directory? If a port has to smart then you may want to split subversion up now because you'll need all that logic for subpackages too. yes to all questions :) that is how subpackage will be, concerning the ETA, now pkg 1.3 has enough support for it, so after EOL of pkg_install I'll push the support for subpackages. regards, Bapt pgpO17iH9UqN5.pgp Description: PGP signature
Re: Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
On Sun, 8 Jun 2014, Lev Serebryakov wrote: Hello, Matthieu. You wrote 8 2014 ?., 15:41:42: MV Holy... MV Is this Debian now? How about 14 packages to have granularity over what MV sub-library needed, and 23 others for each svn* command? And don't forget headers. MV An aspect of ports I liked was it followed/respected the upstream MV packaging mindset, instead of going for artificial repackaging like MV linux distros. This minigame of cutting other people works in tiny MV atomics bits so I have to figure what is missing at runtime is tiresome. MV If this is a binary/options issue, I'd rather see an effort in MV providing a system able to allow using globally packages with local MV build when desired options differs, and the reverse (build everything MV except a list of stuff where binary is prefered). With pkgng in play, I get more and more requests from people, who want to use only binary packages. And when such vital (for many) features as mod_dav_svn and (not so vital, but desirable) DE integration is non-default options of single port, it could not be done. BTW, nobody objects against separated language bindings, especially Java ones :) Really, I get requests to have mod_dav_svn package at least twice a month for all time subversion port exists. But, yes, maybe separation to libraries and binaries is too much, and I need only extract apache-related stuff and DE-related stuff. This is less work and complication, and sounds like it will be enough to satisfy people. Later, if a split into more slave ports is needed, it can be done then. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Splitting devel/subversion into SEVERAL ports -- how fine-grained do we want to see it?
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 l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
