You are not logged in.
Is there a way to express something like the following:
PKGBUILD:depends=('cups' | 'LPRng')
where the '|' character stands for an OR relation ?
Am I right this is not possible, building a custom package with the exact dependencies is the only solution?
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
If those packages provided the same (meta)package, then you could just list the (meta)package that is required. But those are entirely different. What is it that your PKGBUILD actually needs? If it is a specific library, you can just list the library .so file as a dependency. As lprng conflicts with CUPS, I'd gather they both provide some common file - and I'd futher suspect that this file is what you actually need.
Or if these are just entirely different approaches to acheive the same thing and the packaged software will chose whatever is available at runtime, just make them both optional dependencies.
Last edited by Trilby (2018-09-10 14:50:53)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
You are right. I actually need some paths each one provides. For example /usr/lib/cups. I'll have to see what lprng uses.
As I was looking for more data, I saw there is a foomatic-filters-lprng aur package. I would say a dedicated package is the suggested solution by arch. That is, to have a pkg-cups and pkg-lprng. The user should select whether to install pkg-cups or pkg-lprng based on whether he has cups or lprng installed.
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
With foomatic-filters-lprng from the AUR, I got the following:
configure: error: cannot find a2ps, enscript, mpage, or CUPS' texttops. You need to have at least one installed
==> ERROR: A failure occurred in build().
Aborting...
Assuming it is only a makedepends=() thing, are there options other than choosing one of them?
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
I guess you could makedepends on cups, and optdepends on both of them?
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
The package that raised my question is brother-mfc-j480dw from the aur. brother-mfc-j480dw is "LPR and CUPS driver for the Brother MFC-j480DW".
lprng conflicts cups. I don't see how optdepends, suggested by Eschwartz will work.
In the meantime, I have removed cups. So this is a lesser issue for me.
One can argue that in this case, a typical user will have either cups or lprng installed, but not both. So, in this case, it is more theoretical, and less practical, issue.
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
The standard solution provided by ArchLinux is to have both cups and lprng provides the same meta-package as Triby said. You can suggest that to the maintainer of cups and lprng (for example both could provides "print-spooler"). There is no good solution to your problem if you don't have control of cups and lprng. The error in your post about the "configure error" is given by the configure script that is run in the build process, it is not a pacman or makepkg managed thing. What I would do is one of the two things:
1) depends on cups only: it is the spooler used by the vast majority of users.
2) depends of none of them and opt depends of both of them. Possibly put a notice (just uses echo in .INSTALL) to explain the situation. This solution, although imperfect, will normally give the end user enough info to have a working system.
3) If you absolutely want to manage the situation via pacman; you could do the following:
Make an empty package printspooler-cups that "depends" on cups and "provides" "print-spooler".
Make another empty package printspooler-lprng that "depends" on lprng and "provides" "print-spooler"
You probably should make the two empty packages conflicting with each other.
Now make your package depend on "print-spooler".
I am not sure that this complication with two empty packages is really worth it. I would be tempted to use my solution 1) but it's your package, you choose.
Offline