Re: [arch-dev-public] Packages added to todo list 'Fix source file names'
[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? Then should we enforce unique patch names too (and anything else that might go in the source array)? If upstream's tarball is called v0.4.1.tar.gz then I'd rather not override that... -- Gaetan
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
[2015-03-02 12:28:46 -0500] Dave Reisner:
On Mon, Mar 02, 2015 at 06:49:13AM -1000, Gaetan Bisson wrote:
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.
My reasoning is that there's no reason to complicate our PKGBUILDs to fix something I don't consider a problem. We should really just be able to copy-paste an upstream URL; and if the filenames collide I'd rather have this fixed automatically rather than manually in every PKGBUILD.
Another option would be to teach makepkg to shard out SRCDEST by $pkgbase, allowing source contents to be "namespaced" to a degree.
We could also do what wget does: use the full URL as path. So the source file http://github.com/libfoo/v0.4.1.tar.gz would end up being downloaded as $SRCDEST/github.com/libfoo/v0.4.1.tar.gz . That's clean and generic. Are there any tools that rely on SCRDEST and that would be disturbed by a change like this? Cheers. -- Gaetan
On Mon, Mar 2, 2015 at 12:45 PM, Gaetan Bisson
[2015-03-02 12:28:46 -0500] Dave Reisner:
On Mon, Mar 02, 2015 at 06:49:13AM -1000, Gaetan Bisson wrote:
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.
My reasoning is that there's no reason to complicate our PKGBUILDs to fix something I don't consider a problem. We should really just be able to copy-paste an upstream URL; and if the filenames collide I'd rather have this fixed automatically rather than manually in every PKGBUILD.
Another option would be to teach makepkg to shard out SRCDEST by $pkgbase, allowing source contents to be "namespaced" to a degree.
We could also do what wget does: use the full URL as path. So the source file http://github.com/libfoo/v0.4.1.tar.gz would end up being downloaded as $SRCDEST/github.com/libfoo/v0.4.1.tar.gz .
That's clean and generic. Are there any tools that rely on SCRDEST and that would be disturbed by a change like this?
Future plans aside, there are 19 packages involved here. We can spend time proposing alternate solutions without patches and complaining, or we could just fix these packages. I'm glad you don't consider it a problem, but someone cared enough to, and it doesn't really inconvenience anyone that much in the big picture. -Dan
[2015-03-02 12:54:56 -0600] Dan McGee:
Future plans aside, there are 19 packages involved here. We can spend time proposing alternate solutions without patches and complaining, or we could just fix these packages.
I'd rather write a patch myself than see tiny workarounds pile up in our PKGBUILDs. Yes, that's more work, but that's how I prefer to spend my own free time. Now I was discussing whether such a patch is viable before actually working on it. Are you interested in this discussion? -- Gaetan
participants (3)
-
Dan McGee
-
Dave Reisner
-
Gaetan Bisson