Prev: Improving Ada support on FreeBSD and in the ports system
Next: New port: sysutils/megacli waiting to commit
From: Thomas Sandford on 16 Nov 2009 06:09 Peter Jeremy wrote: > 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. >> ... >> 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. Personally I think the performance difference between ..ifdef USE_SVNFETCH ..include "${PORTSDIR}/Mk/bsd.vcs.mk" ..endif in bsd.port.mk and only explicitly including it in the ports that use it is marginal, but I could certainly live with this as a compromise. -- 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: "b. f." on 16 Nov 2009 09:43 >> I was hoping to get a bit more of a response to a recent posting of >> mine with regard to using svn to fetch files for ports >> My proposal: http://www.mail-archive.com/freebsd-ports(a)freebsd.org/msg23776.html >> A summary of what has been going on: >> http://wiki.freebsd.org/EitanAdler/ports-svn > >This was discussed many times before, and this is a bad idea. >- No checksums -> security issue >- No distfile caching/mirroring -> excess traffic consumption and > horrible availability >and I hope you're not even thinking of fetching from VCS without >specifying exact revision. > >Some standard way of generating distfiles from VCS may be nice though, >if it goes into separate mk-file and supports all major VCS. I also think this is a bad idea, even as a separate mk-file, for many of the same reasons. But it could be useful as a script in ports/Tools. _______________________________________________ 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: Doug Barton on 16 Nov 2009 19:01 Thomas Sandford wrote: > If it were just one port and/or just a port maintainers tool I'd agree. > But this is something that affects MULTIPLE ports. You still seem to be advocating the idea of making this a mechanism for users, in spite of the fact that numerous people have said that idea is not likely to ever be approved. Given the universe where this feature is only used by maintainers, a tool script is a good solution. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ 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 17 Nov 2009 16:59 > Actually, I *had* a patch that got the source from svn, tarred it > and checksummed it, with little modification to the do-fetch target > and abusing FETCH_* variables. > The unsolvable problem I ran in to, is that svn doesn't adjust > timestamps for directories on export, so the checksum for the tar > was always different. Hacking svn export was outside my timeframe > and hacking tar to grow an option that sets all created dirs to > a fixed time stamp, seemed too hackish, so I let it go. Creating deterministic tars (ignoring "metadeta") sounds like it should be a solved problem by now. If it isn't then I will have to make it my next project ;) Anyway lets take your script above modify it so that it uploads the tarball to freebsd mirrors and includes the checksum as of the time the maintainer created the tar. This would be much closer to my proposal. _______________________________________________ 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: Scot Hetzel on 17 Nov 2009 19:19
On Tue, Nov 17, 2009 at 3:59 PM, Eitan Adler <eitanadlerlist(a)gmail.com> wrote: >> Actually, I *had* a patch that got the source from svn, tarred it >> and checksummed it, with little modification to the do-fetch target >> and abusing FETCH_* variables. >> The unsolvable problem I ran in to, is that svn doesn't adjust >> timestamps for directories on export, so the checksum for the tar >> was always different. Hacking svn export was outside my timeframe >> and hacking tar to grow an option that sets all created dirs to >> a fixed time stamp, seemed too hackish, so I let it go. > > Creating deterministic tars (ignoring "metadeta") sounds like it > should be a solved problem by now. If it isn't then I will have to > make it my next project ;) > Instead of creating tar files, create zip files and then run them through torrentzip http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/torrentzip/ Torrentzip resets the date/time on the files and directories in the zip archive so that the checksum of the file will match, no matter who builds the zip file using the same set of files. Scot _______________________________________________ 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" |