On Mon, Mar 02, 2015 at 06:49:13AM -1000, Gaetan Bisson wrote:
[2015-03-02 15:58:37 -0000] Arch Website Notification:
Todo list information: Name: Fix source file names URL: https://www.archlinux.org/todo/fix-source-file-names/ Creator: Sergej Pupykin Description: Following packages have potential file name conflicts if you use SRCDEST in makepkg.conf.
Please add "$pkgname-$pkgver.tar.gz::" into beginning of URL.
Urls like this
https://github.com///archive/v0.4.1.tar.gz
should be changed to
$pkgname-$pkgver.tar.gz::https://github.com///archive/v0.4.1.tar.gz
so source will be downloaded into unique named file.
Should we really try to enforce unique tarball names?
Yes. It's rare, but it's easy to fix and it's useful for humans trying to navigate their $SRCDEST directory. A tarball named v0.4.1.tar.gz isn't useful at a glance to a human.
Then should we enforce unique patch names too (and anything else that might go in the source array)?
I don't see why not. If you're giving patches generic names like bugfix.patch, then you're not doing anyone any favors. A sufficiently descriptive filename for a patch should not, in the general case, cause filename clashes.
If upstream's tarball is called v0.4.1.tar.gz then I'd rather not override that...
Not sure you've presented any reasoning here other than "I'm lazy". Don't worry, I'm with you on that, but I think we can do better here without increasing maintenance burden. Another option would be to teach makepkg to shard out SRCDEST by $pkgbase, allowing source contents to be "namespaced" to a degree. This would make the $SRCDEST dir easier to navigate, as everything is now split up by the package it belongs to (and by corollary, it's then easier to clean). A downside is that this strategy would potentially cause source file duplication in cases like "linux" and "linux-api-headers". It also, in extreme circumstances, will break on filesystems like ext3 which have subdirectory count limits. dR