[Fixed] Why there are "-git" packages in AUR?

buhtz · 2022-10-24 08:52:42

Hello,

I'm not an Arch user so I maybe miss some basic knowledge about Arch and your packaging process. But I want to learn and that is why I ask this question.

As an example "backintime-git"
https://aur.archlinux.org/cgit/aur.git/ … intime-git

This is a community maintained package, right?

What I wonder is the "-git" in the name. That package seems to be build directly from the latest upstream master. No commit hash or release tag is used. So the code could be brocken and unstable in the upstream's master branch.

Why does a Arch user would like to have such an unstable package?

Isn't it the usual way to directly git clone from the upstream repo if someone really needs the lates code basis, e.g. for testing purposes?

Last edited by buhtz (2022-10-24 10:18:54)

SanskritFritz · 2022-10-24 09:17:05

It occured many times in my Arch journey that I found a bug upstream, reported it, and got back a request to test the latest git head. However I was not sure how to build the application properly, so the -git package in AUR was godsent. I was able to quickly test the application and report back upstream. Also, the -git package is designed in a way that you only have to rebuild it, to automatically have the last head packaged. So if I want to have the very latest bells and whistles in an application with the caveat they can be unstable sometimes, -git packages come to the rescue.

ayekat · 2022-10-24 09:18:52

buhtz wrote:

Why does a Arch user would like to have such an unstable package?

Maybe for testing or development purposes. Or because they need a feature that isn't present in the latest stable release (and backporting would be too cumbersome). Or because they have shiny object syndrome, and it's just "the newest".
There are many usecases for that.

Also, depending on the software project, the master branch may be relatively reliable, so there aren't too many issues with using that.

sn't it the usual way to directly git clone from the upstream repo if someone really needs the lates code basis, e.g. for testing purposes?

Yes, but you don't want to just download it and look at the code. You probably still want to install it to the system for testing, so you probably want to package it some way.

buhtz · 2022-10-24 09:20:37

Dear Fritz,
thanks for your reply.

So is it usual to have "-git" packages? How many are there?
And does every Arch user know the difference between a stable and a "-git" package?

OK, I can confirm that the "how to build" description of "backintime" wasn't the best in the past.

buhtz · 2022-10-24 09:24:21

ayekat wrote:

buhtz wrote:
Why does a Arch user would like to have such an unstable package?
Maybe for testing or development purposes. Or because they need a feature that isn't present in the latest stable release (and backporting would be too cumbersome). Or because they have shiny object syndrome, and it's just "the newest".
There are many usecases for that.

But my point or thought is that this usecases can be full filled with "git clone" from upstream.

ayekat wrote:

but you don't want to just download it and look at the code. You probably still want to install it to the system for testing, so you probably want to package it some way.

But e.g. "backintime" does over a "make" target for that. And a modern python repo should over setup.cfg (setuptools) which can be used to build/install it. Backintime will offer that in the future, too.

I don't want to convince you. I just tried to understand the Arch universe.

ayekat · 2022-10-24 09:34:24

buhtz wrote:

But my point or thought is that this usecases can be full filled with "git clone" from upstream.

But that way, you only have the sources. You still want to test-install it to the system, no? (at least I'd want to do that, also as an upstream)

Just running programs out of a project source directory might be fine for the regular development cycle, but not for extended/thorough testing.
Or for any of the other usecases.

But e.g. "backintime" does over a "make" target for that. And a modern python repo should over setup.cfg (setuptools) which can be used to build/install it. Backintime will offer that in the future, too.

The equivalent of `make install` for directly installing something into a system is heavily discouraged (no matter which distro by the way).

If you limit the installation to somewhere within your home directory (e.g. with python envvars), then yes, that can limit or avoid issues. But the same on a system level (i.e. `sudo make install` or equivalent) is just a recipe for problems, because there'd be tonnes of untracked files scattered across the system that will potentially conflict with distro packages.

Packaging is usually the cleanest option for installing software, and if people already do that for your unreleased code, you get the added benefit of noticing issues with your software before they make it into the release.
Like the LC_ALL issue.

Last edited by ayekat (2022-10-24 09:38:17)

buhtz · 2022-10-24 09:38:36

Thanks a lot for explaining to me.

For the future: How can I distinguish between stable and unstable Arch packages?

From Debian I know the different branches "stable", "unstable", "testing", "experimental", etc.

In Arch is there only the "-git" string in the package name? Is this a standard?

ayekat · 2022-10-24 09:53:10

buhtz wrote:

For the future: How can I distinguish between stable and unstable Arch packages?
From Debian I know the different branches "stable", "unstable", "testing", "experimental", etc.

Arch doesn't really have a concept of "stable" or "unstable". It's just "rolling" (i.e. it generally packages the latest stable release of each software as they are released).

There is a testing, but that's more of a space where (new versions of) packages are pushed and kept for some period before being propagated to the main repos. But the testing state is not reflected in the package name.

In Arch is there only the "-git" string in the package name? Is this a standard?

-git just means the package is built from an (untagged/unspecified) commit from the upstream project (usually from the master/main/… branch). This follows the general VCS packaging guidelines and also applies to -svn, -hg, -cvs, etc.
I guess by definition one could probably consider those to be "unstable" (as they're not packaging a stable/released version of software).

Or rather: If I have a -git/-cvs/-svn package in front of me, I know it wasn't built from a stable upstream release.

Note that the AUR is not part of Arch proper, but rather just a place where users can upload their packaging suggestions (though de facto most users treat it as Yet Another Software Source, which is not necessarily great). You won't find any -git packages in the Arch repos.

schard · 2022-10-24 11:48:06

buhtz wrote:

So the code could be brocken and unstable in the upstream's master branch.

If I'd give a version tag to a broken commit, it's still broken.
The fact, that the main branch is used has nothing to do with code quality or stability.
It is merely another means of versioning the code, i.e. by using the commit tags.
If a software project follows Arch's philosophy of rolling release it is sensible to develop the latest version on the main branch and build packages from there - no need to hassle with counted versions.
And if the project uses some form of continuous delivery and proper unit testing, all commits of the main development branch are guaranteed to be in a well-tested state (though nothing is ever guaranteed to be bug-free).

Trilby · 2022-10-24 12:56:00

schard wrote:

If I'd give a version tag to a broken commit, it's still broken.

This.

Buhtz, you are confusing / conflating two completely different uses of the word "stable". Upstream authors can / do release "stable" snapshots of their code with tagged releases. They also have the current development code generally made available (sometimes via git, or mercurial, or in my case fossil, or any number of other vcss). But then you draw an analogy to debian "stable" vs testing. But these two uses of "stable" are completely different things.

Debian's "stable" repositories, just like arch linux's main repos (core/extra/community) are a managed set of packages that have gone through some degree of testing by the distro maintainers to make sure they all function together properly. There are lots of AUR packages that use a tagged release (and so in the first meaning of the word they are "stable") despite not getting any testing whatsoever from any distro developer. In fact all AUR packages, by definition, are not stable in the second definition of the term. Some of them (those ending with -git, -hg, -fossil, etc) are not stable in either definition.

Keep in mind too, which Schard highlighted, that there is yet a third definition of "stable" that is a bit different from either of the above too in meaning trustworthy and / or relatively bug free. There is some overlap in the first definition (developer curated packages) and this third one (trustworthy and relatively bug-free) but they are not identical.

In quite a few cases, the unstable (1st definition) packages that are also unstable (2nd definition) will be the most stable (3rd definition) ones available as they've had the most recent bug fixes / security patches.

Last edited by Trilby (2022-10-24 12:58:02)

Arch Linux

#1 2022-10-24 08:52:42

[Fixed] Why there are "-git" packages in AUR?

#2 2022-10-24 09:17:05

Re: [Fixed] Why there are "-git" packages in AUR?

#3 2022-10-24 09:18:52

Re: [Fixed] Why there are "-git" packages in AUR?

#4 2022-10-24 09:20:37

Re: [Fixed] Why there are "-git" packages in AUR?

#5 2022-10-24 09:24:21

Re: [Fixed] Why there are "-git" packages in AUR?

#6 2022-10-24 09:34:24

Re: [Fixed] Why there are "-git" packages in AUR?

#7 2022-10-24 09:38:36

Re: [Fixed] Why there are "-git" packages in AUR?

#8 2022-10-24 09:53:10

Re: [Fixed] Why there are "-git" packages in AUR?

#9 2022-10-24 11:48:06

Re: [Fixed] Why there are "-git" packages in AUR?

#10 2022-10-24 12:56:00

Re: [Fixed] Why there are "-git" packages in AUR?

Board footer