How do development updates work in Pamac?

[hwittenborn]

What exactly is going on to let Pamac know that updates for things like Git packages are available?

[bogdancovaciu]

Is all dependent on the branch you are using, and since you mentioned

@hwittenborn

Git packages

i guess you are referring to KDE-unstable repository … or, since you tagged AUR you are referring to AUR packages? Is your Pamac Preferences set like this?

If an AUR package will have updates, then it will notify you and you then can update it.

[mithrial]

I think she wants to know how pamac knows when there’s a new release for the *-git packages. They are not updated in the AUR, meaning the version string in the AUR doesn’t change.

[hwittenborn]

i guess you are referring to KDE-unstable repository … or, since you tagged AUR you are referring to AUR packages? Is your Pamac Preferences set like this?

I’m actually working on an AUR-like platform for Debian-based systems and likewise a helper for the platform, and I’d like to look into implementing updates for Git packages on the platform (so yeah, basically anything that ends in -git like @mithrial said).

My problem is knowing what source(s) I should check for updates from. I’m thinking I could use the url field, or something in source (or multiple), but I’m not sure what should be implemented. I was mainly wondering what Pamac was doing so I could possibly base it off of that.

I think she wants to know how pamac knows when there’s a new release for the *-git packages.

FWIW I’m a male. I’m gonna try to blame it on the profile filter for the time being

[moson]

@hwittenborn

I was mainly wondering what Pamac was doing so I could possibly base it off of that.

Not sure how pamac handles that. (now I do. See below)

I can tell how yay does this though:

Basically it creates a local “database” (well, it just is some file with json data in it) where it stores the package-name, url and the commit hash for all -git packages that are installed.

Example:

"cvt12-git": {
		"github.com/kevinlekiller/cvt_modeline_calculator_12.git": {
			"protocols": [
				"https"
			],
			"branch": "HEAD",
			"sha": "4dd2e548663b3d441bd63c85eb15ff8e44ee43bc"
		}
	},
	"linux-firmware-git": {
		"git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git": {
			"protocols": [
				"https"
			],
			"branch": "HEAD",
			"sha": "d79c26779d459063b8052b7fe0a48bce4e08d0d9"
		}
	}

Now when you search devel package updates, it will check if the locally stored hash value matches the last commit in the git repository from the package.

If they match → Nothing to update
If they don’t → Well, there is a new commit, let’s rebuild it.

edit

Here’s how pamac handles it:

https://gitlab.manjaro.org/applications/libpamac/-/blob/master/src/database.vala#L2378

It’s basically running makepkg without building the package (just downloading) and then it generates .SRCINFO and compares the resulting version against the locally installed one.

https://gitlab.manjaro.org/applications/libpamac/-/blob/master/src/database.vala#L2606

That explains why it’s taking ages if you have a lot -git packages. It always downloads all sources for each package you’ve installed.

The yay way is better and faster, imho.

[hwittenborn]

@moson

Basically it creates a local “database” (well, it just is some file with json data in it) where it stores the package-name, url and the commit hash for all -git packages that are installed.

Just so I can confirm, but yay is assuming the url variable in the PKGBUILD is the source to check for updates from?

@moson

It’s basically running makepkg without building the package (just downloading) and then it generates .SRCINFO and compares the resulting version against the locally installed one.

That would just be utilizing the pkgver() function then, right?

If I went with that last approach, that would have to trust the maintainer didn’t put anything malicious inside the function, right?

[moson]

@hwittenborn

but yay is assuming the url variable in the PKGBUILD is the source to check for updates from?

From .SRCINFO I guess, but yeah that comes from PKGBUILD, source…

@hwittenborn

That would just be utilizing the pkgver() function then, right?

I think so, yes.