From: Thomas Sandford on
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
>> 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
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
> 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
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"