You are not logged in.

#1 2020-04-20 09:44:16

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 758
Website

[SOLVED] git PKGBUILD - sparse checkout possible?

Is it possible to sparse-checkout a Git source in a PKGBUILD?
I want to do something like:

git clone <URL> --no-checkout <directory>
cd <directory>
git sparse-checkout init --cone
git sparse-checkout set drivers/hid/amd-sfh-hid

Last edited by schard (2020-04-20 10:37:39)

Offline

#2 2020-04-20 10:18:26

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 9,708
Website

Re: [SOLVED] git PKGBUILD - sparse checkout possible?

No: https://lists.archlinux.org/pipermail/a … 39586.html

EDIT: that was for shallow clones. I'm not sure what the difference between sparse and shallow is, but I suspect the answer is still the same.

Last edited by WorMzy (2020-04-20 10:21:16)


Sakura:-
Mobo: MSI X299 TOMAHAWK ARCTIC // Processor: Intel Core i7-7820X 3.6GHz // GFX: nVidia GeForce GTX 970 // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 5x 1TB HDD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

#3 2020-04-20 10:37:26

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 758
Website

Re: [SOLVED] git PKGBUILD - sparse checkout possible?

Alright then.
I'm not using a pkgver() function, but I can see why Eli et al. refused to add this.
The whole repo it is then.

Offline

#4 2020-04-20 13:04:37

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,321

Re: [SOLVED] git PKGBUILD - sparse checkout possible?

shallow clones are definitely out, because of a variety of reasons. I can't think of a principled reason to say "no way in hell" to sparse checkout, so in theory that should be fine...

But how, exactly, would you communicate this to makepkg? Note that makepkg completely handles the process of fetching a bare repository into $SRCDEST, and then checks this out into the $srcdir. You'd want to somehow override the checkout-into-srcdir logic, which is something that would normally be handled by noextract=() for plain files, but at the same time you need to link the git repo into the srcdir so the user can manually handle this...

I need to think about this. I don't want to add yet more grammar to the source=() array, nor to invite the same complexity into noextract=().

...

I suggest removing "[SOLVED]" from the thread title, unless you consider it solved because now you know it isn't currently possible. It's premature to predict it won't be added in the future.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2020-04-30 14:26:14

daniel_shub
Member
Registered: 2012-06-21
Posts: 45

Re: [SOLVED] git PKGBUILD - sparse checkout possible?

I proposed a way to make a shallow clone with a custom dlagent a while back on stack exchange https://unix.stackexchange.com/a/155052/22724 . I don't see why that approach wouldn't work for sparse clones.

Offline

#6 2020-04-30 14:33:00

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,479
Website

Re: [SOLVED] git PKGBUILD - sparse checkout possible?

What about the old-school mechanism of handling vcs sources: get the source in the prepare function?  I still have to do this in PKGBUILDs for fossil sources as makepkg doesn't handle them.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#7 2020-04-30 14:48:51

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,321

Re: [SOLVED] git PKGBUILD - sparse checkout possible?

daniel_shub wrote:

I proposed a way to make a shallow clone with a custom dlagent a while back on stack exchange https://unix.stackexchange.com/a/155052/22724 . I don't see why that approach wouldn't work for sparse clones.

Maybe it would, maybe it wouldn't.

All I know is that cloning without the full history won't be officially supported, and I won't try to speculate on how to do it since I'm not really interested in this.

Hacking it with custom DLAGENTs is, after all, a hack. And DLAGENTS dispatches this through code intended to handle single files, not VCS clients, so it seems... fragile... by default.

Given the OP wants sparse-checkout clones, not shallow clones, this deserves better. I'm sure it can be properly supported in a safe, reliable, official way.

Last edited by eschwartz (2020-04-30 14:57:27)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB