svn commit: r381760 - in head/x11-fonts/sourcesanspro-ttf: . files

[Adam Weinberger]

> On 21 Mar, 2015, at 9:03, Alexey Dokuchaev <danfe at FreeBSD.org> wrote:
> 
> On Fri, Mar 20, 2015 at 12:43:17PM -0600, Adam Weinberger wrote:
>> It would be so unbelievably nice if we had a way to just specify the
>> destination filename, using fetch -o. All the bizarre names that files
>> are published as, the unversioned tarballs, the documentation files
>> labelled Documentation.pdf, and the fallout from changes like this....
>> we could make our lives so much easier with a DISTFILE_DEST variable.
> 
> Current situation with the distfiles in the industry is indeed very bad.
> Old-skool folks that obeyed the rule of "foo-0.42.tar.gz" distfile which
> extracts into "foo-0.42" directory, fetchable as regular file with known
> Content-Length and Last-Modified headers (to allow working progress bars
> and sane mirroring) are minority now, and soon may cease to exist.
> 
> New-age hipsters tell you to "always git clone, no thinking required" and
> rarely care to upload ./configure-ready tarball, or at least tag their
> releases so GH can try to provide reliably fetchable and mirrorable files.
> 
> As to Adam's idea, I don't see what can be done, apart from tell upstream
> how important it is to produce normal old-fashioned releases from time to
> time.
> 
> 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?
> 
> ./danfe
> 
> P.S.  No wonder sf.net is still alive: they know how to maintain sane
> CDN for tarballs and data, which backs up all their drawbacks.

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.

We may be able to do a little more to work around the fact that now the most common distfile producer (GitHub) names directories strangely... something like

_WRKSRC_POSSIBILITIES != ls ${WRKDIR} | ${GREP} -ci ${PORTNAME}
.if _WRKSRC_POSSIBILITIES == 1
WRKSRC != ls ${WRKDIR} | ${GREP} -ci ${PORTNAME}
.endif

But it looks like that's no longer an issue with our new USE_GITHUB.

# Adam


-- 
Adam Weinberger
adamw at adamw.org
http://www.adamw.org