RFC: svn for make fetch
in [Ports]
|
Prev: Improving Ada support on FreeBSD and in the ports system
Next: New port: sysutils/megacli waiting to commit
From: Wesley Shields on 12 Nov 2009 20:10 On Tue, Nov 10, 2009 at 10:28:17PM +0200, Eitan Adler wrote: > Alright - I updated the wiki page to summarize the thread so far. > I'd appreciate if people could comment on the "spec" part > specifically. I'd like to see that section become much more specific > (so that I could use it to unambiguously write something based off of > it) > > I'm holding off on writing any new implementations at the moment to > see where things head in terms of how things should be done. > http://wiki.freebsd.org/EitanAdler/ports-svn Why only SVN? I'm not trying to be picky but if we start supporting this for SVN it's very easy to argue we should support it for some other VCS. Personally I think this kind of thing is best left up to the maintainer to use his/her custom scripts and not stuff support for it into the ports infrastructure. -- WXS _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Eitan Adler on 13 Nov 2009 03:00 Actually I was thinking of eventually adding non-svn support as well.... The reason I started on this project is because the version of mplayer in ports is severely out of date. When I tried to update to port I noticed that the project wants you to compile and install from svn. I also noticed a few other ports that have hacks to let the maintainers "use his/her custom scripts" stuck into the port's Makefile. I think it would be good if there was some standardized way of solving both of these problems... On Fri, Nov 13, 2009 at 3:10 AM, Wesley Shields <wxs(a)freebsd.org> wrote: > On Tue, Nov 10, 2009 at 10:28:17PM +0200, Eitan Adler wrote: > > Alright - I updated the wiki page to summarize the thread so far. > > I'd appreciate if people could comment on the "spec" part > > specifically. I'd like to see that section become much more specific > > (so that I could use it to unambiguously write something based off of > > it) > > > > I'm holding off on writing any new implementations at the moment to > > see where things head in terms of how things should be done. > > http://wiki.freebsd.org/EitanAdler/ports-svn > > Why only SVN? I'm not trying to be picky but if we start supporting this > for SVN it's very easy to argue we should support it for some other VCS. > Personally I think this kind of thing is best left up to the maintainer > to use his/her custom scripts and not stuff support for it into the > ports infrastructure. > > -- WXS > _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Wesley Shields on 13 Nov 2009 15:06 On Fri, Nov 13, 2009 at 10:00:08AM +0200, Eitan Adler wrote: > Actually I was thinking of eventually adding non-svn support as well.... I don't think bloating bsd.*.mk for the most common VCS out there is a good idea, not to mention what happens when someone wants support for some oddball VCS that is not normally used? > The reason I started on this project is because the version of mplayer in > ports is severely out of date. When I tried to update to port I noticed that > the project wants you to compile and install from svn. I also noticed a few > other ports that have hacks to let the maintainers "use his/her custom > scripts" stuck into the port's Makefile. I think it would be good if there > was some standardized way of solving both of these problems... Sure, but it doesn't belong in bsd.*.mk. Turn it into a script and submit it as a regular port. -- WXS _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Thomas Sandford on 14 Nov 2009 10:46 Wesley Shields wrote: > On Fri, Nov 13, 2009 at 10:00:08AM +0200, Eitan Adler wrote: >> Actually I was thinking of eventually adding non-svn support as well.... > > I don't think bloating bsd.*.mk for the most common VCS out there is a > good idea, not to mention what happens when someone wants support for > some oddball VCS that is not normally used? > >> The reason I started on this project is because the version of mplayer in >> ports is severely out of date. When I tried to update to port I noticed that >> the project wants you to compile and install from svn. I also noticed a few >> other ports that have hacks to let the maintainers "use his/her custom >> scripts" stuck into the port's Makefile. I think it would be good if there >> was some standardized way of solving both of these problems... > > Sure, but it doesn't belong in bsd.*.mk. Turn it into a script and > submit it as a regular port. If it were just one port and/or just a port maintainers tool I'd agree. But this is something that affects MULTIPLE ports. Surely the whole value/purpose of the ports build infrastructure is to present a consistent way of doing things rather than different maintainers doing their own thing and solving problems in different, and quite possibly sub-optimal ways and/or bloating multiple individual port Makefiles with what could be kept in a single bsd.*.mk file. And if the file were (say) bsd.vcs.mk and were pulled in only if one of USE_SVNFETCH USE_CVSFETCH USE_GITFETCH etc were defined then the impact of the bloat on other ports is minimal. A quick scan of ports reveals that the following contain the string "svn export" in their Makefile ports/cad/kicad-devel ports/comms/wsjt ports/comms/wspr ports/devel/compiler-rt ports/devel/llvm-devel ports/devel/thrift ports/games/evq3 ports/games/q2pro ports/games/freeorion ports/games/worldofpadman ports/net-im/cjc ports/www/twiki ports/www/foswiki ports/x11-toolkits/gigi This thread has revealed at least two further ports that use a svn distribution but where this is hidden from the user. That's 15 ports already that could be sharing common code instead of doing it themselves. How many do you need? -- Thomas Sandford _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Peter Jeremy on 15 Nov 2009 15:48
On 2009-Nov-14 15:46:27 +0000, Thomas Sandford <freebsduser(a)paradisegreen.co.uk> wrote: >Wesley Shields wrote: >> Sure, but it doesn't belong in bsd.*.mk. Turn it into a script and >> submit it as a regular port. > >If it were just one port and/or just a port maintainers tool I'd agree. >But this is something that affects MULTIPLE ports. Based on your numbers, 15 ports - less that 0.1% of the ports tree. >Surely the whole value/purpose of the ports build infrastructure is to >present a consistent way of doing things rather than different >maintainers doing their own thing and solving problems in different, and >quite possibly sub-optimal ways and/or bloating multiple individual port >Makefiles with what could be kept in a single bsd.*.mk file. If it affected several hundred ports and/or was visible to the end user then this might be justification for embedding it into bsd.*.mk. The ports build infrastructure is already quite large (>20K LOC) and difficult to follow. The overheads associated with loading bsd.*.mk files also makes operations like "make index" very time-consuming. IMHO, bloating it further to marginally simplify life for the maintainers of ~15 ports is not a good tradeoff. Wesley's suggestion above sounds like the best solution. >And if the file were (say) bsd.vcs.mk and were pulled in only if one of > >USE_SVNFETCH >USE_CVSFETCH >USE_GITFETCH > >etc were defined then the impact of the bloat on other ports is minimal. If you still want to go this way, I'd suggest writing a stand-alone bsd.vcs.mk that can be .include'd by the port when it needs the functionality. -- Peter Jeremy |