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
