[aur-requests] [PRQ#10670] Deletion Request for dune

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-requests/attachments/20180220/abf63f9d/attachment-0001.asc>