Jordan K. Hubbard wrote:
>> But that would still require a network access to get that info,
>> even if was better than the previous (having to download them).
>
> First, that's a cool little hack with "curl getsize" and definitely the way
> I'd implement it if I had to since hard-coding it with the distfiles
> themselves leaves you now with *three* things to update every time a port
> changes: The name of the distfile (if it can't be derived), its checksum(s)
> and its length. Slippery slope, to say the least.
Currently, we are updating four: version (i.e. affecting the distfile), md5,
sha1, rmd160. Just saying that it would be less clutter to have, say "SIZE" and
"SHA256" collected in a "distinfo" file, since that's what FreeBSD Ports is
using... ("make makesum") Just an observation from using both ports systems,
really.
> A bigger and more pertinent question, however, is just what the utility of
> this feature is supposed to be since the compressed tarball only represents a
> small percentage of the space required by macports, even on a "package
> server" (should one ever exist), for each individual port. As the (now) old
> saying also goes, "disk space is cheap!" and tarballs are fungible on any
> type of machine where that's not likely to be true, so again, I don't see a
> valuable usage case?
As with most of the other hacks, it doesn't have a use case or any other reason
for existance other than "it was there" or "question was out". It started out
as a question of "how big is a port", and thus it was implemented. Since most
distfiles are mirrored now anyway, I guess it's much easier now to collect
stats ?
--anders
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
