bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Creating a formula for Homebrew


From: Simon Josefsson
Subject: Re: Creating a formula for Homebrew
Date: Fri, 26 Aug 2022 09:11:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Bruno Haible <bruno@clisp.org> writes:

> Hi,
>
> Wesley Viana wrote:
>> So I was wondering how to contribute by "packing" gnulib into a brew
>> formula.
>
> Packaging gnulib through a packaging system (such as Debian, pkg, BSD ports,
> or brew) is, in the current state of things, not desirable.
>
> Gnulib is a source code library [1], and, although the documentation states
> that the user has the choice between using the git repo and stable releases 
> [2],
> there have not been such stable releases for 4 years. That is, everyone uses
> the git repo. And we are taking QA steps to ensure a high quality of the
> code in the git repo.

Whilke I agree with the above, I do believe there is a way to package
gnulib in packaging systems that make sense: by packging the gnulib git
repository including its entire git history, and keep that "package" up
to date regulary.  After all, that is the way developers use gnulib: it
is a source-archive, and every git commit is a release that somebody may
want to use.

The source of the problem I see described in this thread is that
distributions (for good reasons) wants to rebuild everything from
source, and building from tarballs is quite fragile: it is difficult to
know if you rebuilt everything from its pure source code or accidentally
just re-used a pre-built artifact.  The alternative that people have
adopted in recent years is to build from version controlled sources and
going through the bootstraps steps themselves (usually quite poorly, by
just calling autoreconf -fvi which was never intended for that purpose),
and if done right I think this results in something that is better for
distributions.

Building from git introduces two new problems: 1) not using officiall
release tarball artifacts, introducing unreliability in what a release
is, including what cryptographic signatures to trust, and 2) any git
submodules (such as gnulib) and external resources (like translation
files) needs to be available offline locally in a package.

Translation files is tricky, and I'm not sure how to resolve that in a
good way.  There is no strong connection between a git repo and the
translation file intended to be used with it, introducing unreliability
and supply-chain issues.  Perhaps the solution is similar to the gnulib
packaging: just package all translationproject.org *.po files in a
separate package in the distribution, and keep that up to date, and use
that as the source during source-code rebuilds.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]