On 02/20/2018 09:24 PM, Jakob Gahde via aur-requests wrote:
So now on to the technical side.
1. Personally I used to be a big fan of namcap myself, but over time I’ve come to take it’s output with a grain of salt. It gets a lot of the basics right and is very helpful for some easy-to-miss stuff (like a dependency on glibc), but it tends to miss or get wrong a lot of the more “advanced” aspects. I’ve been planning for ages to look into contributing to it, but to this day I’m not even sure where it’s maintained :/
I would argue that this is something it gets wrong. :p The base group *is* our official installation instructions, and any system that does not have glibc installed is so broken it's not even funny... That being said, I'm not the maintainer and obviously I've never bothered to move to have glibc special cased so it will not be suggested. But if you have any desire to contribute to namcap one way or a completely unrelated way, you can file bugs to bugs.archlinux.org -- just use the "Arch Linux" project[1] and select the "Arch Projects" category. The git repository is of course at https://git.archlinux.org/namcap.git/
3. ocaml-findlib is something that OCaml software uses to, well, find libraries. Since it provides wrappers around the compiler and such, older build systems like OASIS also rely on it for the build procedure and installation, but newer OCaml build systems like dune and some others (don’t remember exactly which ones) can do much of their work without it, despite still integrating with it. Hence why it’s in fact an optional dependency for dune and not a hard dependency. Most of the current packaging guidelines for OCaml actually seem to be geared towards software using OASIS as build system, and I suppose that’s the main reason for why it’s in makedepends, even though OASIS seems to be on a decline. But I have to admit that I didn’t exactly pay a lot of attention to this whole affair myself, and I should probably have a proper look at it. Maybe I could also update the wiki page while I’m at it, the last meaningful changes were made way back in 2012. Since “package guidelines” has a somewhat official sound to it, do you happen to know whether the contents of these pages are coordinated somehow or whether they are basically community-maintained?
They are community maintained *guidelines* that are programming language specific. Contrast this to the Arch Packaging Standards, which are locked for editing and require discussion on the talk pages in order to convince a wiki admin to implement any desired rewording. If you say something obviously wrong, I'm sure someone somewhere will be delighted to correct you... but this is really no different from any other wiki page.
4. Thanks for pointing out that problem when comparing versions, I never noticed that. As for my opinion, I think moving the package to community is a good opportunity to “fix” the versioning. We can notify people as you suggested, and the ones who don’t get the notification will still see a message à la “warning: dune: local (1.0+beta17-1) is newer than community (1.0b17-1)” when performing sysupgrades.
It is considered best practices to ensure that packages migrated to community undergo a monotonic version upgrade. If epoch is what it takes to get back onto a consistent *and sane* versioning scheme, then so be it... Switching *back* to a version scheme that will require you to add another epoch every time you package a +beta and then want to switch to a newer, yet lesser final release, doesn't seem very wise. So Bruno, your options are either 1) Add an epoch now and use a pacman-conformant versioning schema, or 2) Continue to use a pacman-conformant versioning schema, but don't bother with an epoch. Users will "downgrade" by hand, or else finally notice the update whenever version 1.1 renders this moot. Do you have a timeframe on that? :p I'll also just throw this out there: some Devs/TUs will drop an epoch that existed in the AUR if it seems silly, because epoch is gross and only used as a last resort and the AUR is after all "unsupported". While still being quite willing to bump the pkgrel in order to enable smooth upgrades. [1] https://bugs.archlinux.org/index.php?project=1 -- Eli Schwartz Bug Wrangler and Trusted User