[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cgit .tar.gz code snapshots
From: |
Simon Josefsson |
Subject: |
Re: cgit .tar.gz code snapshots |
Date: |
Tue, 31 Dec 2024 18:47:59 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
fosslinux <fosslinux@aussies.space> writes:
> On 12/29/24 23:38, Simon Josefsson wrote:
>> sön 2024-12-29 klockan 21:18 +1100 skrev fosslinux:
>>>> Could live-bootstrap start to use git cloning? Maybe we can win
>>>> this
>>>> particular example, but I suspect the question will come back
>>>> again.
>>> Without going into our technical structure - yes and no. However, we
>>> are actively moving away from dynamically generated
>>> tarballs (to making them ourselves from Git clones), not just for
>>> gnulib, but for everything where we consume a Git
>>> snapshot. We can get past this issue ourselves. However, at this
>>> point gnulib effectively has a dependency on git to use
>>> -- depends on how you feel about that how problematic that is.
>> I'm not really sure I understand everything here -- but my idea is to
>> publish a gnulib snapshot on ftp.gnu.org eventually with a 'git
>> bundle'. It will contain all previous git commits of the gnulib
>> repository. No need for thousands and thousands of different gnulib
>> 'git archive' tarballs. Your workflow could be:
>>
>> wget https://ftp.gnu.org/gnu/gnulib/gnulib-20250115.bundle
>> git clone gnulib-20250115.bundle gnulib
>> cd gnulib
>> git checkout 2d1c0b2f38c81d1c8eca2f06b39264f5029b97fe
>>
>> or whatever. It can be used as a --gnulib-refdir or --gnulib-srcdir
>> depending on your build flow.
>> My plan is to include this bundle into the Debian gnulib package too,
>> so eventually this is just:
>>
>> apt-get install gnulib
>> git clone /usr/share/gnulib/gnulib.bundle gnulib
>> cd gnulib
>> git checkout ...
>>
>> Is this relevant to what you are doing?
>
> Ahh, okay; currently, no, this doesn't really help us (not as a
> concept, and especially not it existing in Debian). However I think it
> is a good idea anyway :)
>
> We only use a subset of gnulib commits, but we *need* at least some of
> those as tarballs. Our problem is how do we get them as tarballs:
> previously, we used dynamically generated tarballs; now, we are
> exploring different options, most probably making them ourselves using
> git archive.
I see. There is a gnulib mirror available where you can get
commit-based tarballs from here:
wget -nv
https://gitlab.com/libidn/gnulib-mirror/-/archive/$GNULIB_REVISION/gnulib-mirror-$GNULIB_REVISION.tar.gz
This is neither an official mirror (I operate it) nor a trustworthy way
of getting gnulib source code from. I hope that we can publish a git
bundle eventually, to offer some form of serialized archival non-https
way of getting gnulib, even if that isn't something you can make use of
today. Publishing tarballs for every commits seems really wasteful,
there must be some better way.
/Simon
signature.asc
Description: PGP signature