Arch Linux User Repository

If having this error, just a rebuild is needed:

Traceback (most recent call last):
  File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 397, in from_name
    return next(cls.discover(name=name))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
StopIteration

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/git-imerge", line 33, in <module>
    sys.exit(load_entry_point('git-imerge==1.2.0', 'console_scripts', 'git-imerge')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/bin/git-imerge", line 22, in importlib_load_entry_point
    for entry_point in distribution(dist_name).entry_points
                       ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 862, in distribution
    return Distribution.from_name(distribution_name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 399, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: No package metadata was found for git-imerge

@Eschwartz First, clearly we disagree completely on this. Setting the version shows nothing of what you claim it shows; it only shows that I set the version, nothing more, nothing less.

Second, getting the version into the package requires an extra step, makepkg --printsrcinfo >| .SRCINFO, all other things are equal.

Third, if your interest really is "sharing that knowledge and helping users and maintainers share packages in a more effective and intuitive manner", then maybe you should consider how you communicate. With the style you've used in this case you have managed to come across as a smart Alec who likes teaching grandma to suck eggs; you haven't taught me anything I didn't already know, you haven't been helpful, you haven't provided any guidance in how I can be more effective in sharing packages, all you have achieved is that I now contribute less to AUR. What is most important to you, that there are users willing to put packages on AUR, or that every package on AUR conform to your "implicit customs"?

If 0.7.0-44-g59af371-1 was the latest version at the time the PKGBUILD was modified, then setting the pkgrel to 0.7.0-44-g59af371-2 for over two years would guarantee that the version monotonically updated, and that all users were notified to use the updated version. Yes.

Furthermore, it would tell users that 2 years ago you checked that it was working with the pkgver 0.7.0-44-g59af371-2, that being the last time the PKGBUILD needed modifications (and in many cases this lets people determine which upstream commits were the trigger for modified build steps, in case they wish to bisect for some reason).

Finally, it literally requires more effort to go back and revert the pkgver than to simply commit the updated version along with whichever other changes caused you to commit an updated -git PKGBUILD in the first place.

tl;dr git packages are no different from regular packages, and follow all the same rules, except for the fact that they are not flagged out of date for upstream releases.

...

I don't feel strongly about this package, I feel strongly about Arch packaging in general. I'm a TU, I review PKGBUILDs in the forums, on the mailing lists, and in #archlinux-aur, I do makepkg development, I maintain Arch Linux's official dbscripts, and in general am quite interested in, well, packaging.

My interest here is in sharing that knowledge and helping users and maintainers share packages in a more effective and intuitive manner.

@Eschwartz But please, this is a -git package. There are no upstream releases for this package to follow.

According to your reasoning users of the package would have been more helped by having a pkgver set to 0.7.0-44-g59af371 for two years. That's simply not true, it would have been exactly as helpful as having it set to 0.

All I'm trying to make clear to you is that all the statements and rules you bring up are completely true for ordinary packages. However, for -git packages they don't make any difference because the correct metadata isn't known when I write and upload the PKGBUILD, it's only known when the user runs makepkg.

I'm not sure how you can be a maintainer of numerous -git packages without realising this. Is there a reason you like carrying out unnecessary and pointless steps in your maintenance of packages?

Since you clearly feel strongly about this package I'll disown it so you can take over. Thanks!

According to your reasoning, the AUR shouldn't bother listing versions for anything. Is there a reason you hate your users?

I'm not sure how you've been a maintainer of packages for 5 years without having realized this.

Please read the PKGBUILD(5) manpage and take a look at the "pkgrel" section. Updating the pkgver may be an implicit custom, but updating the pkgrel is merely the difference between right and wrong. I'm telling you for an absolute fact that you're doing it wrong.

Packages must update monotonically for every upstream update which in the case of git packages means using the pkgver function. They must also update monotonically as a second-level (pkgrel) update when the PKGBUILD itself changes. The pkgrel update brings in the pkgver update as a dependency. Failure to do this makes it categorically impossible to determine via metadata whether or not the new package was built with the updated PKGBUILD or whether it was built in between the last upstream commit and your change.

Your habit of using "0" was just ugly and breaking custom (take a look at the AUR and see how many of the packages you use list "0" as a version)... up until you updated the PKGBUILD for the first time. At that point your failure to provide a monotonically updating version for your PKGBUILD changes migrated from ugly to wrong.

Your PKGBUILD is now wrong.

...

Was I clear enough this time?

@Eschwartz So the short of it is, a version of 0 doesn't break any tool and apparently there's an "implicit custom" that I've never heard of before, nor noticed in any of the -git packages I have installed and keep up-to-date.

Given that the "implicit custom" really is of very little practical use, I'll just leave the version at 0 and let users of this -git package keep an eye on upstream for updates... the same as one has to do with all -git packages.

@magus, the problem here is not necessarily that a version of 0 breaks version comparison, it is the fact that the version manifestly is not and never has been 0. The fact that it was committed as such almost implies you've never tried installing it, since makepkg would overwrite the 0 with the version at the time of building...

More specifically though, you've updated the PKGBUILD in the past with changes that affect the built package, and you did not bump the pkgrel to ensure people would actually install the updated version. Bumping the pkgrel implies that you've also updated the pkgver to the current version.

This would ensure that people looking for updates to AUR packages would detect that this package is more up-to-date than the version they have installed (due to the pkgver being equal to or greater than their currently installed version, and the pkgrel being greater thereby ensuring that the combined pkgver-pkgrel in the AUR is more recent than the pkgver-pkgrel for the outdated package they have installed without git completion).

It is very much the implicit custom of AUR packagers to commit the latest generated pkgver() along with whatever other changes they have made. Even for -git packages -- in fact, especially for AUR packages, because an updated pkgver is a prerequisite to setting pkgrel=2.

This really has nothing to do with special-casing the "0" case.

EDIT: also that build function is ridiculous. Please delete this eyesore. If people feel weirdly compulsive need to know that there's nothing to build... well, makepkg cleverly doesn't claim to be running a build function if there is no build function to build.

@rafasc In what way is having it set to 0 breaking version comparison?

Can you please update pkgver? Having it set to 0 is breaking version comparison. https://bpaste.net/show/49d2baa11f56