makepkg and pollution of the SRCDEST namespace [SOLVED]

Profjim · 2009-07-08 22:09:30

Suppose one has SRCDEST set in /etc/makepkg.conf, so that all the non-local entries in a PKGBUILD's source array get downloaded to that folder.

Now most such entries are going to have package-specific (and often even version-specific) names. But sometimes not.

For example, in one PKGBUILD I have (a home-spun one, I'm not sure if this affects any PKGBUILDs already out there on AUR) I want to download some documentation files to add to the install. The url for one of these ends ".../manual.html". So I get a "manual.html" file in my SRCDEST directory. From some other PKGBUILD, for similar reasons, I also get a bare "FAQ.html" file. And so on.

Could be trouble if I start using multiple PKGBUILDs that try to download files with the same basename.

Of course, this could be caught by the md5sums not matching when you try to build against a source file that really belongs to a different package. But (1) when I'm making packages for my own use, and I'm including additional source files like documentation and so on, I'll often omit including md5sums for them. I don't care if the relevant files change upstream. And (2) if I alternate using package A and B which both try to save a source file with the same basename to SRCDEST, it's somewhat wasteful to have the different source files downloaded anew everytime.

This could also be avoided by not using a SRCDEST variable, and just having sources saved in the same directory as the PKGBUILD. But I'm exploring whether it's possible to fix the problem while still using a shared SRCDEST for all of one's packages.

It seems like the best solution would be some way to tell makepkg "here's the url to download the file from, but you should name it this instead." If we had that, it would at the same time solve a related problem: some upstream sources don't put version numbers on their sources. (For instance, the cococpp package has this problem.) So building can fail in a confusing way: the sources download fine but then fail the md5sum check. And if you just update the package version in the PKGBUILD, you have to then remember to go delete the source file (off in your SRCDEST directory), else makepkg will just use the older, cached source file without noticing it doesn't match the new version you've requested. Again, we could fix this if we could tell makepkg to rename a source file as it downloads it.

Is there any elegant way to do this, with existing resources? Or would it require a change to makepkg?

I can think of some non-elegant ways to do it:

1. Don't include the file in the sources array, but instead put handwritten instructions to check-for-cached-file-else-download-and-rename in the build() function.

2. Use a special wrapper script in the /etc/makepkg.conf DLAGENTS array. The wrapper script would parse the source array entry and extract special markup indicating how to name the downloaded file. (But then how to get makepkg to know to look for the source file using the downloaded name? Well, perhaps we could use "url#extra_tag" as the source array, which you'd pass to wget to download "url" and save as "url#extra_tag", then makepkg would already be looking for an existing "url#extra_tag" by default.)

I'm not sure how often this problem might arise. But it seems reasonable to think about solutions rather than just cross our fingers and hope different packages will never have namespace-collisions of this sort. If we're going to support the use of SRCDEST at all.

Any other ideas?

Last edited by Profjim (2009-07-08 22:30:24)

arkham · 2009-07-08 22:14:40

From man pkgbuild:

It is also possible to specify an optional filename, which is helpful with weird URLs and for handling multiple source files with the same name. The syntax is: source=('filename::url')

Profjim · 2009-07-08 22:30:01

Perfect! I've looked for that, though not recently. Stupid of me not to look again before posting. Thanks, arkham.

Arch Linux

#1 2009-07-08 22:09:30

makepkg and pollution of the SRCDEST namespace [SOLVED]

#2 2009-07-08 22:14:40

Re: makepkg and pollution of the SRCDEST namespace [SOLVED]

#3 2009-07-08 22:30:01

Re: makepkg and pollution of the SRCDEST namespace [SOLVED]

Board footer