[aur-general] Handling of virtual packages

buckket buckket at cock.li
Tue Sep 20 20:12:26 UTC 2016


Hey,

I’m currently maintaining serval packages on the AUR which are all
implementations of djb’s redo[0], an incremental build system. However
there are minor differences between all those implementations, and as
djb never wrote one himself there is no "offical" one. That’s why I
decided to give the packages unique names like "redo-sh"[1] and let them
all provide[2] "redo" in their PKGBUILD.

Coming from Debian I’m familiar with the concept of virtual packages[3]
like www-browser[4], which makes it easy do specify a general dependency
without getting to specific about it.

As there some programs out there which use redo’s .do files in their
building process it’s important that they can specify redo, or any of
the existing implementations in their makedepends. But as far as I know
there is no way to specify either package A OR B as a dependency for
package C, so I came to the conclusion that using such a virtual package
would make perfect sense and is the only valid option here.

I already saw that "sh" is used like this, but I found no official
resources on how Arch or the AUR handles such cases.

Also someone just recently created a "redo" package which is in fact
just one of the many implementations, which I find kinda problematic.
Especially if somebody doesn’t know about the current status of the redo
ecosystem.

So if anybody knows about the modus operandi in such cases I’d be glad
to hear about it.

Regards,
Felix

[0] http://cr.yp.to/redo.html
[1] https://aur.archlinux.org/packages/redo-sh
[2] https://wiki.archlinux.org/index.php/PKGBUILD#provides
[3] https://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg
[4] https://packages.debian.org/jessie/www-browser

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20160920/f22a9500/attachment.asc>


More information about the aur-general mailing list