Date: Sat, 21 Mar 2015 15:31:44 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Adam Weinberger <adamw@adamw.org> Cc: svn-ports-head@freebsd.org, Baptiste Daroussin <bapt@FreeBSD.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, Bryan Drewery <bdrewery@FreeBSD.org> Subject: Re: svn commit: r381760 - in head/x11-fonts/sourcesanspro-ttf: . files Message-ID: <20150321153144.GA96276@FreeBSD.org> In-Reply-To: <5F4F2275-6F2D-43CC-ACB4-1B8240D5A5B3@adamw.org> References: <201503201823.t2KIN32I080448@svn.freebsd.org> <550C6655.5010802@FreeBSD.org> <20150320183524.GD87678@ivaldir.etoilebsd.net> <9BE33FCA-5C2F-4FEA-9B3A-5D9DB6632635@adamw.org> <20150321150350.GB55163@FreeBSD.org> <5F4F2275-6F2D-43CC-ACB4-1B8240D5A5B3@adamw.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 21, 2015 at 09:20:59AM -0600, Adam Weinberger wrote:
> > On 21 Mar, 2015, at 9:03, Alexey Dokuchaev <danfe@FreeBSD.org> wrote:
> > DISTFILE_DEST, while looking good at the first glance, raises at least
> > some important questions of its own: how do we mirror these files? What
> > should be their mtime, so mirrors won't have to refetch the same bits all
> > over again? Do we need/want to maintain relationship between upstream
> > and our DISTFILE_DEST'ied name, and how do we do it if we do?
>
> Those are really good points. I guess if distfiles were stored on
> MASTER_SITE_BACKUP in a /${UNIQUENAME}/ subdir they could continue to be
> named what they're originally named. That way the relationship is that
> things on MASTER_SITE* are the original name, and it's only on the client
> machine that the distfiles are renamed.
Basically, to deal with unversioned tarballs and Documentation.pdf files we
had a solution for years: DIST_SUBDIR. I'd be glad to have something more
robust, but don't see good alternative ATM. Even if try to transfer mtime
of the original badly-named distfile to DISTFILE_DEST, this already smells
weird. :(
Since right now we seem to be talking about GH mostly, I hope Bryan et al.
can find a way to deal with it without having to bring in some disruptive
changes to our framework.
./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150321153144.GA96276>