Re: fibers release bits [was: Re: Moving Fibers to Codeberg]

Tomas Volf <[email protected]> Wed, 03 Dec 2025 19:53:19 +0100

Newsgroups	gmane.lisp.guile.user
Message-ID	<[email protected]>

Ludovic Courtès <[email protected]> writes:

> Greg Troxel <[email protected]> skribis:
>
>> Generally, not really, but we cope with all sorts of things when we have
>> to.  Typically packages that need a git checkout are in the
>> new/not-really-baked upstream stage.
>>
>> What pkgsrc -- and I'd expect just about every other packaging system
>> including GNU/Linux distributions -- expects is to download a release
>> tarball from a URL.  It is rare for that not to be available, and pretty
>> much unheard of for a healthy project (that is maintained, has
>> releases).  Fibers appears healthy except for not having tarballs.
>
> My view as a packager is that release tarballs are on the decline.  In
> Guix, 12k packages out of 30k (38%) have their source taken from a
> tarball; see also figures 3 and 4 of
> <https://hal.science/hal-04586520v1> for the general trend.

Probably depends on the point of view, but I would say these numbers are
bit skewed by number of libraries for modern languages (golang, rust,
ruby, ...), which are technically packages in Guix.

In some other distributions lot of them would not even exists.  For
example, Archlinux packages go-md2man, as does Guix, but it does not
have go-github-com-cpuguy83-go-md2man-v2 package.  So in Guix that are 2
packages fetched from git, while only 1 in Archlinux.

Additionally, I have noticed the trend in Guix to switch to git source
even when the tarball does exist.  This again skews the numbers a bit,
no idea how much.

Though I am not disputing the trend (as much as I do not like it), just
the specific numbers.

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

signature.asc (application/pgp-signature, 853 B)