[aur-general] please add -depth 1 to makepkg git clone
1. save bandwidth 2. less wait why not add --depth 1 :)
On Fri, Apr 5, 2013 at 2:12 AM, Tai-Lin Chu <tailinchu@gmail.com> wrote:
1. save bandwidth 2. less wait
why not add --depth 1 :)
If you're using a git package, I assume you're updating it at some frequency and you only have a full clone on the first build.
you mean pkgver()? On Thu, Apr 4, 2013 at 11:14 PM, Daniel Micay <danielmicay@gmail.com> wrote:
On Fri, Apr 5, 2013 at 2:12 AM, Tai-Lin Chu <tailinchu@gmail.com> wrote:
1. save bandwidth 2. less wait
why not add --depth 1 :)
If you're using a git package, I assume you're updating it at some frequency and you only have a full clone on the first build.
if add --depth 1, please set to option enable or disable it 2013/4/5 Tai-Lin Chu <tailinchu@gmail.com>:
you mean pkgver()?
On Thu, Apr 4, 2013 at 11:14 PM, Daniel Micay <danielmicay@gmail.com> wrote:
On Fri, Apr 5, 2013 at 2:12 AM, Tai-Lin Chu <tailinchu@gmail.com> wrote:
1. save bandwidth 2. less wait
why not add --depth 1 :)
If you're using a git package, I assume you're updating it at some frequency and you only have a full clone on the first build.
----------------------------------------
Date: Thu, 4 Apr 2013 23:12:29 -0700 From: tailinchu@gmail.com To: aur-general@archlinux.org Subject: [aur-general] please add -depth 1 to makepkg git clone
1. save bandwidth 2. less wait
why not add --depth 1 :)
Please don't, it will screw up just about every method of updating pkgver.
Am 05.04.2013 08:12, schrieb Tai-Lin Chu:
1. save bandwidth 2. less wait
why not add --depth 1 :)
because you can't do nearly anything git related with this clone. You can't clone, can't update, etc. Best workflow is * clone the repo (like downloading a source package) * on all following calls do an update * then do a clone to do the build (even here without '--depth 1' because local clones are cheap) * before the next build only remove the build-clone With this workflow you only need to clone the repo once and then work with your local copy. I don't know exactly what automatic the new makepkg implements for repository sources, but I think it will do the first two steps above. So the PKGBUILD only has to provide the clone for the build (if the sources are not prepared for out-of-source builds). Hope this helps Uwe
hmm.. not true sometimes. I will just post the definition here because I feel people dont understand shallow clone well. The --depth 1 option in git clone: Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. so, 1. you can also do the "pull once use forever" 2. you cannot push to that repo anymore (but who really needs to anyway?) the only drawback i can see: 1. the git rev-list count head hack does not work. but should we just clone the whole thing for the pkgver? (notice, for example, tweeter bootstrap: 26mb vs 3mb with shallow clone) On Fri, Apr 5, 2013 at 6:41 AM, Uwe Koloska <kolewu@koloro.de> wrote:
Am 05.04.2013 08:12, schrieb Tai-Lin Chu:
1. save bandwidth 2. less wait
why not add --depth 1 :)
because you can't do nearly anything git related with this clone. You can't clone, can't update, etc.
Best workflow is * clone the repo (like downloading a source package) * on all following calls do an update * then do a clone to do the build (even here without '--depth 1' because local clones are cheap) * before the next build only remove the build-clone
With this workflow you only need to clone the repo once and then work with your local copy.
I don't know exactly what automatic the new makepkg implements for repository sources, but I think it will do the first two steps above.
So the PKGBUILD only has to provide the clone for the build (if the sources are not prepared for out-of-source builds).
Hope this helps Uwe
On Thu, Apr 04, 2013 at 11:12:29PM -0700, Tai-Lin Chu wrote:
1. save bandwidth 2. less wait
why not add --depth 1 :)
I have tested this out on many repos (including the linux git repository) and the bandwidth saved is so minimal it's not even worth it. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
@William Giokas really? tweeter bootstrap saves 88% vlc saves 87% make sure you dont read the wrong number. On Fri, Apr 5, 2013 at 6:17 PM, William Giokas <1007380@gmail.com> wrote:
On Thu, Apr 04, 2013 at 11:12:29PM -0700, Tai-Lin Chu wrote:
1. save bandwidth 2. less wait
why not add --depth 1 :)
I have tested this out on many repos (including the linux git repository) and the bandwidth saved is so minimal it's not even worth it.
-- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
On Fri, Apr 05, 2013 at 06:40:33PM -0700, Tai-Lin Chu wrote:
@William Giokas really? tweeter bootstrap saves 88% vlc saves 87%
make sure you dont read the wrong number.
Okay, I take that back. The clones are significantly smaller[0], but at the same time, I will argue that these git repositories should be as full as possible, seeing as people using the -git packages should not be just building them for fun, but should have a reason to be using these unstable sources (ie: developing, testing, etc.). If you're using these just for fun, then something is wrong. It's like installing Arch: the first time it's all of the set up, but to keep it up to date is simple. I use linux-mainline, and get the sources from git. The original clone was pretty big, but pulling from git I think it takes ~1M/week. This is still a -1 from me, unless it is configurable, though the vcs urls are already pretty full (vcs+file::url#fragment=xyz), and I think it should be on a per-repo basis, not in the OPTIONS array. [0]: Cloning into bare repository 'shallow'... remote: Counting objects: 1046, done. remote: Compressing objects: 100% (953/953), done. remote: Total 1046 (delta 376), reused 518 (delta 52) Receiving objects: 100% (1046/1046), 2.65 MiB, done. Resolving deltas: 100% (376/376), done. Cloning into bare repository 'full'... remote: Counting objects: 75015, done. remote: Compressing objects: 100% (19022/19022), done. remote: Total 75015 (delta 53683), reused 72896 (delta 51870) Receiving objects: 100% (75015/75015), 15.71 MiB | 10.33 MiB/s, done. Resolving deltas: 100% (53683/53683), done. (I don't know what I was thinking there...probably screwed up the git command when i tested it last.) Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
On Fri, Apr 5, 2013 at 8:12 AM, Tai-Lin Chu <tailinchu@gmail.com> wrote:
1. save bandwidth 2. less wait
why not add --depth 1 :)
Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build.
makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions On Fri, Apr 5, 2013 at 6:43 PM, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:
On Fri, Apr 5, 2013 at 8:12 AM, Tai-Lin Chu <tailinchu@gmail.com> wrote:
1. save bandwidth 2. less wait
why not add --depth 1 :)
Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build.
On Fri, Apr 05, 2013 at 06:47:55PM -0700, Tai-Lin Chu wrote:
makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions
Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build.
This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
1. you can still pull, so it will not be a reason to go against it
This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does.
2. ... i dont think why it needs to use git clone. using cp is good enough... On Fri, Apr 5, 2013 at 7:05 PM, William Giokas <1007380@gmail.com> wrote:
On Fri, Apr 05, 2013 at 06:47:55PM -0700, Tai-Lin Chu wrote:
makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions
Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build.
This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does.
Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
On Fri, Apr 05, 2013 at 07:35:15PM -0700, Tai-Lin Chu wrote:
1. you can still pull, so it will not be a reason to go against it
Okay, say that I run $ git clone --bare --depth 1 git://some.repo.git foo blah blah clone clone...etc. $ git clone foo foo-local-clone Cloning into 'shallowclone'... fatal: attempt to fetch/clone from a shallow repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. And here is what makepkg does with git sources: 1) clones a bare repository into SRCDEST 2) verifies the checksum, which should be 'SKIP' for these kinds of sources 3) clones the SRCDEST repo into the BUILDDIR, $srcdir. If it can't complete this final step, then you have no sources to work with and makepkg is worthless for git sources.
This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does.
2. ... i dont think why it needs to use git clone. using cp is good enough...
Using git clone preserves every file to the smallest detail. cp makes no such guarantees. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tai-Lin Chu <tailinchu@gmail.com> wrote:
1. you can still pull, so it will not be a reason to go against it
This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does.
2. ... i dont think why it needs to use git clone. using cp is good enough...
On Fri, Apr 5, 2013 at 7:05 PM, William Giokas <1007380@gmail.com> wrote:
On Fri, Apr 05, 2013 at 06:47:55PM -0700, Tai-Lin Chu wrote:
makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions
Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build.
This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does.
Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
This is dumb because using cp is not enough, you should be using git clone because it is git and straight from git, if you goal is to just use the newest you are doing it wrong go write you own pkgbuild. The only reason to use git packages is if you are deving upstream and want to actively test development of upstream packages... Or if up stream is dumb enough to never tag stable releases. Fortunately there are very few of the latter, so to support the majority of of users we clone the whole thing. You are welcome to use the old method if you are so naive to believe that people will actually benefit from a true shallow clone of a git repository though yaourt. Because no one should ever install a git I ask age through yaourt because it is deleted immediately. - -- Sent from my Android Phone. Daniel Wallace Arch Linux Trusted User GTManfred -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iQFUBAEBCAA+BQJRX7PvNxxEYW5pZWwgV2FsbGFjZSAoZ3RtYW5mcmVkKSA8ZGFu aWVsLndhbGxhY2VAZ2F0ZWNoLmVkdT4ACgkQX6XlVE8BDUjm8ggAkOdV8r/bQHy9 mE1XtFAu6T+j83leaRugchsK9sIzKAKjfEHThpfO/nG6MBVPNytjqVhgyqrsHgr9 1ItAl3VrdbjFmQpRplBvYz8dAkid5pq2ZdG9f/ildROkirxCzPkevCjTenmouxY6 oY4vXUFthc7WOtviaQ1U9+pSmgrzTWvCrzlyZG1tPRlxRVYDHTPpVzxhtOrExUhy rAF6MOry5u3tww/mHigNwQPW6kVVh1nB5lWhoJ5PIY7cENKXJP7o+npV2Hb9TCGr djrFOCg+ZaeeX/gK93cI6BigiF5XdAFnPhpiQpoLXvUiD050bOoj5d7tKb+be7Ba FGrXvqNPlg== =EBW2 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tai-Lin Chu <tailinchu@gmail.com> wrote:
1. you can still pull, so it will not be a reason to go against it
This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does.
2. ... i dont think why it needs to use git clone. using cp is good enough...
On Fri, Apr 5, 2013 at 7:05 PM, William Giokas <1007380@gmail.com> wrote:
On Fri, Apr 05, 2013 at 06:47:55PM -0700, Tai-Lin Chu wrote:
makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions
Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build.
This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does.
Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
I truly do not understand why this conversation exists. We discussed this months ago. The conclusion was that you really shouldn't be using these packages unless you are following upstream... What if the current depth=1 is unstable and has a huge bug.... Then what... Oh those users aren't following upstream and have no idea because instead of the developers of the program monitoring and telling them this a stable (and hopefully bug free release... The use your depth=1 pkgbuild and never update until one of the depends does a soname bump and breaks everything... To save space... In my opinion we should actually remove git packages from the aur... It adds an air of instability to the distribution... People that use -git should really maintain there own pkgbuild... And yes I felt this was so important I interrupted my night out to send... So, unlike you, I hope depth is never supported in package source=() - -- Sent from my Android Phone. Daniel Wallace Arch Linux Trusted User GTManfred -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iQFUBAEBCAA+BQJRX7eRNxxEYW5pZWwgV2FsbGFjZSAoZ3RtYW5mcmVkKSA8ZGFu aWVsLndhbGxhY2VAZ2F0ZWNoLmVkdT4ACgkQX6XlVE8BDUiGAgf/TywmVGiCUD7h gwAa41u43M9v890Suf2Io9x37ptiVJ6vGcwx5iWKJVct8r6TSh0xvavZo3VRW3G3 9mVst9HVSa16tMBXelVMGC2h1dawH2MYi8Jy1/L453133hFTqkIAOKPRX+QF+c5o /8xU3sXog/115n2UiYnn2PymsnYen+xHxdrW4x3nGDJYFFwUlDVq+YmRRFjZrz+/ a2sP5RkK0isv4U3h57bnb2mwQrZscV/IYMUrBmhHhaWZpErBx2EnZlm/PYjrnYEE D+CNmaYoVh7zdKbI+X+1/cY4E2OSSRgwK8IU8gM7mXkw447VjASDf2s/RnyxOPND ENGX7R1V2A== =PNi3 -----END PGP SIGNATURE-----
participants (8)
-
Daniel Micay
-
Daniel Wallace
-
Doug Newgard
-
Jan Alexander Steffens
-
SpinFlo
-
Tai-Lin Chu
-
Uwe Koloska
-
William Giokas