Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#59485 - [makepkg] hg support for repos containing subrepos is broken

Attached to Project: Pacman
Opened by Earnestly (Earnest) - Monday, 30 July 2018, 10:36 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 30 July 2018, 17:11 GMT
Task Type Bug Report
Category makepkg
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 5.1.0
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

When attempting to package coin3d with source=('hg+https://bitbucket.org/Coin3D/coin') I get the following error during extraction:

==> Extracting sources...
-> Creating working copy of coin hg repo...
updating to branch default
abort: repository /home/earnest/local/src/generalmsvcgeneration not found!

Now ideally I would not want this code, along with the other sub repositories this project contains but it appears impossible to avoid this problem with murcurial.

Here is a "solution" someone came up with but I somehow doubt this is reasonable in an automated environment: https://stackoverflow.com/a/27387352

More information: https://www.mercurial-scm.org/wiki/Subrepository

The only possible workaround I can think of is to explicitly order all of the subrepositores (I'm not sure how url backed entries will work) prior to the main repository in the source=() array.
This task depends upon

Comment by Eli Schwartz (eschwartz) - Monday, 30 July 2018, 17:16 GMT
As mentioned in IRC, no clue what to do about this. :D It's an interesting demonstration of how mercurial itself is basically broken, though.

I think, if we are going to do something about this, it will most likely end up being PKGBUILD(5) documentation on the limits of mercurial.
People who need to use repositories like this, might have to revert to the bad old days and clone the repo during prepare(), sadly.

NB: someone should file a mercurial bug asking for an option to disable or delay this until an explicit "submodule update" style action.
Comment by Earnestly (Earnest) - Tuesday, 31 July 2018, 14:15 GMT
Keeping everything to a fairly bare example, this is what I am essentially using to workaround the limitation:

prepare() {
if [[ ! -d $SRCDEST/repo ]]; then
hg clone -U https://repo.org/repo "$SRCDEST"/repo
elif (( ! HOLDVER )); then
hg --cwd "$SRCDEST"/repo pull
fi

if [[ -d $srcdir/repo ]]; then
hg --cwd "$srcdir"/repo pull
hg --cwd "$srcdir"/repo revert -a -r tip -X a -X b -X c
else
hg clone -U "$SRCDEST"/repo "$srcdir"/repo
hg --cwd "$srcdir"/repo revert -a -r tip -X a -X b -X c
fi
}

Where 'a', 'b', and 'c' are subrepositories in the above.

A potential solution for makepkg might be to employ these sorts of commands where the -X flags are synthesised by parsing the .hgsub file within the repository, e.g.

while read -r subrepo _; do
exclude+=(-X "$subrepo")
done < .hgsub

hg revert -a -r "$ref" "${exclude[@]}"

However how this information is passed to source/hg.sh would be up for debate, it could potentially be used as a query much like ?signed for git currently is. Unlike ?signed the -X can be specified multiple times and include url-like paths. I don't have any good ideas or suggests to handle these issues yet.

Loading...