[pacman-dev] [PATCH 0/2] makepkg: Allow placing local sources in subdirectories

[Eli Schwartz]

On 04/28/2018 04:31 AM, Vladimir Panteleev wrote:
> Currently, makepkg doesn't support (actually, mishandles) sources in a
> subdirectory of the package directory. Though there aren't many uses
> for such a feature, it is useful for an otherwise source-less package
> of Arch- or site-specific scripts, to be installed on one or a few
> systems, for which it doesn't make sense to have a separate source
> repository. In this case, it would be nice to either move the source
> files in a subdirectory, or allow pulling them from somewhere else on
> the filesystem.
> 
> Whether or not this is considered a valid usecase, the current
> behavior is broken (makepkg computes broken paths and attempts to
> operate on files that aren't there), so this probably ought to be
> fixed regardless.
Also https://bugs.archlinux.org/task/39718

I'm not sure we have a specified behavior, but I'm personally of the
opinion this should be prohibited. IMHO there is no reason to hide files
in subdirectories when the entire directory with the PKGBUILD is meant
to be the package sources etc.

If we did support it officially, we should make sure --source supports
it too, and possibly decide whether we support this in the AUR as well.

An argument could be made BTW, that these source paths are in fact
malformed and should possibly be file://$(pwd)/ urls which are
downloaded via curl according to the intent of the PKGBUILD author
(these would then be downloaded from a local URI). The logical extension
of that line of thought, is we should add a lint_pkgbuild check with a
more informative error when no protocol is specified, but a non-filename
is used.

Yes, file:/// sources work fine. If it isn't specifically local:// then
download_file is used, which does DLAGENTS lookup. We don't provide a
"file" DLAGENTS protocol, which means we usually just silently exit that
function without actually downloading anything... but nothing is
stopping people from adding one in the PKGBUILD itself. curl supports
downloading from file:///absolute/path/to/file

...

I *really* dislike the inconsistency of permitting subdirs for local
files (implying we think this is a reasonable use case) but not
permitting them for things we resolve as something to download.

> I couldn't find a test suite for makepkg (only pacman and
> makepkg-template), so, here is the test case:
> 
> mkdir dir
> touch a dir/b /tmp/c
> cat > PKGBUILD <<'EOF'
> pkgname=dir-test
> pkgver=1
> pkgrel=1
> arch=('any')
> source=(a dir/b /tmp/c)
> md5sums=(SKIP SKIP SKIP)
> package() { cp "$srcdir"/* "$pkgdir/" ; }
> EOF

How would this handle the second case being, instead, local://dir/b ?

The proto=local semantic is used both for files that don't have a proto,
and files which use the local:// proto. The local:// proto is *actually*
used, believe it or not. It's how we specify that the user is expected
to provide the file themselves, for e.g. AUR packages which require
proprietary sources (like games hidden behind paywalls). The AUR checks
the proto, to make sure that no-proto files which *are* expected to be
provided together with the PKGBUILD are not missing.

...

Why don't people use, for the third case,
DLAGENTS+=('file::/usr/bin/curl -C - -o %o %u'); source=('file:///tmp/c') ?

And what sources do we expect to have a guaranteed filesystem location,
but are not supplied by a package? I consider cp during build/package to
be perfectly adequate for files provided by some other package, and in
fact I use this here:

https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/broadcom-wl&id=fba4c424ae9bc381f0babc61fca4643e1569de1a#n31

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20180428/944a7e56/attachment.asc>