[arch-dev-public] Packages added to todo list 'Fix source file names'

Dave Reisner d at falconindy.com
Mon Mar 2 17:28:46 UTC 2015

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.


More information about the arch-dev-public mailing list