Filesize in Portfiles (was Re: [76684] trunk/dports/sysutils/rpm/Portfile)

[Anders F Björklund]

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