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

[Eli Schwartz]

On 04/29/2018 06:17 AM, Allan McRae wrote:
> Firstly, we do not consider the AUR when making development decisions.

Well, yeah, I'll have to raise that separately on aur-dev based on the
outcome of this discussion.

(Also it is relevant at least in the sense that the nature of the AUR
ensures the local:// protocol gets used in real-world cases.)

> Also, I am thinking you are mixing up --source and --allsource.

No, when neither file:// nor local:// are used --source should be adding
it as well, which means this applies to that too AFAICT.

> I am happy for a file:// protocol to be added.  We already use it for
> dealing with local packages/repos in pacman, so it should be supported
> for pacman.  In fact, I thought this had already been done, so was
> surprised when it did not work!

Makes sense... I do wonder how many AUR packages incorrectly use file://
(no default DLAGENT handler) instead of local:// (explicitly disables
DLAGENT handling) and will therefore break as a result. We'll get more
technical correctness out of this, which is neat!

> As far as the justification for source=("foo/bar") type sources, I think
> reasonable arguments can be made for their inclusion.  For VCS sources,
> I think a git submodule is a valid example.  Also, consider gcc - if you
> download a source for (e.g.) gmp into a particular directory in its
> sources, it will compile it and build against that.  And the simple
> example provided by OP of config files organised in different
> subdirectories relative to the PKGBUILD also seems reasonable.  So,
> sources downloaded to subdirectories is a feature I would support
> implementing.

Reasonable enough. I'd forgotten about VCS submodules, this could
actually simplify handling a lot, there...

But I'm not sure how we'd handle that properly. We use bare clones, so
there are potential file/directory name conflicts that would not
normally manifest in the git worktree (which relies on the developer
layout that explicitly handles that).
It's also quite ugly IMO to do bare git clones recursively into each other.

BTW we've been asked for this before: https://bugs.archlinux.org/task/39718

> However, I will not consider partial solutions - or more accurately,
> partial fixes that look like that will need partially reverted to
> implement the complete solution.  On the top of my head, the complete
> solution covers:
> 
> 1) files in subdirectories of the builddir.
> 2) standard sources
> 3) VCS sources
> 4) Sources with foo/bar::http:// type syntax
> 5) --allsource

I think a solution would probably look like:

1) add file:// DLAGENTS. As you pointed out, it's useful, a common URI
scheme, and should be there regardless.

2) add support for proto:// downloads to subdirectories, requires
pre-creating directory layout I think, plus passing the correct paths in
download_foo to the DLAGENT. All DLAGENTS should natively support
writing to any relative specified path, we just don't use that.

3) ensuring extract_foo handles the requested $srcdir layout. This is
where FS#39718 bites us.

4) ensure source packages correctly generate. This should be sufficient
to modify:

ln -s "$absfile" "$srclinks/$pkgbase"

to create the right destination, and mkdir -p the ${destination/*} first.

-- 
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/20180429/f4b45fcc/attachment-0001.asc>