You are not logged in.

#1 2020-07-19 10:16:38

Sergy
Member
Registered: 2020-02-14
Posts: 6

How to deal with mutuality exclusive opt-depends

This is my first ever package build and I am working my way through a list of questions.

Background: I've written a simple python script that changes the desktop wallpaper at any given interval. The desktop is changed to a full HD image that is being broadcasted by Google (it taps into the streamurls used by the chromecast device).

It works on KDE-plasma and Gnome desktops. In order for the script to work either geckodriver or chromedriver needs to be installed.

Problem / question: The dependencies needed by the script in order to work properly depend upon wheter the user is running the KDE-plasma or Gnome desktop environment and wheter the user has either gecko- or chromiumdriver installed.  Now > how do I translate this into the PKGBUILD depends and opt-depends?

I've figured for myself that maybe I need to create multiple packages, e.g. a KDE-package & Gnome-package and then in both packages list both geckodriver and chromiumdriver as an opt-depend > then in the opt-depend-description mention that either geckodriver or chromiumdriver needs to be installed..

But it feels like there should be a more clean approach to this?

Offline

#2 2020-07-19 11:04:16

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: How to deal with mutuality exclusive opt-depends

Geckodriver and chromedriver don't seem to conflict, so could both be installed.
I'd expect the python script to be able to select one of them, maybe use a simple per-user configuration file ?

The dependencies may be more complicated though.
Will your script work when geckodriver is present but there's no gecko-based browser installed ?

Chromedriver appears to target chrome exclusively, will your script run if only chromedriver is present ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#3 2020-07-19 14:46:24

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: How to deal with mutuality exclusive opt-depends

Sergy wrote:

Problem / question: The dependencies needed by the script in order to work properly depend upon wheter the user is running the KDE-plasma or Gnome desktop environment

pacman cannot possibly know which DE the user selects at login time.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#4 2020-07-19 18:16:31

ondoho
Member
Registered: 2013-04-30
Posts: 692
Website

Re: How to deal with mutuality exclusive opt-depends

^ This.
Can't you just have both drivers in optdepends, and then the script makes choices during runtime, if it can reliably find out which DE is running?

Offline

#5 2020-07-20 06:54:41

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

Re: How to deal with mutuality exclusive opt-depends

The only way with pacman to ensure at least one of those is installed is to have both package provide the same name and then having your package depend on that (like `webdriver`).

Unfortunately, you can't possibly anticipate all different uses (and reverse dependencies) of a package ahead of time, so an alternative hackworkaround is to create metapackages that fill the missing gap, e.g.:

pkgbase=webdriver
pkgname=(webdriver-chrome webdriver-gecko)
pkgver=2020.07.20
pkgrel=1
arch=(any)
provides=(webdriver)

package_webdriver-chrome() {
  depends=(chromedriver)
}

package_webdriver-gecko() {
  depends=(geckodriver)
}

This is cleaner than stating optdepends on two packages and trusting the user to manually resolve dependencies, as it properly codifies the requirements with pacman's own mechanisms.
The downside is that you need those 2 additional metapackages for this.

Last edited by ayekat (2020-07-20 07:00:13)


pkgshackscfgblag

Offline

#6 2020-07-20 21:37:47

Sergy
Member
Registered: 2020-02-14
Posts: 6

Re: How to deal with mutuality exclusive opt-depends

Thanks for all the answers. I thought I might be overlooking some obvious resolution but it appears I am not and there are different approaches to tackle this problem.

Working with the metapackages seems like the most clean solution as I would indeed like for the package to install by itself without relying (too much) on user choices (this goed against the Arch philosophy of letting the user decide, yet this package is more a proof of concept in which I try to create a PKGBUILD that will actually install my own script on my multiple Arch desktops that all have different configurations/setups).

The 'mutually-exclusive' in the title of the question might be a misinterpretation though. I realise geckodriver and chromedriver can be installed side-by-side and also KDE-plasma & Gnome could both be installed. So they are not in fact mutually-exclusive.

However, my script at minimum needs one of each (so either gecko- or chromedriver and either KDE or Gnome) to work. But it would be a major overkill to install all of them simply to run an autamatic wallpaper changer. That said, if none of them is installed the script won't work, so they are definitaly a dependency.

On further note. The script itself already tries to figure out in which DE it is running via the following setup:

if "plasma" in os.environ.get('DESKTOP_SESSION'):
        kde_command = "qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.evaluateScript 'var allDesktops = desktops();print (allDesktops);for (i=0;i<allDesktops.length;i++) {d = allDesktops[i];d.wallpaperPlugin = \"org.kde.image\";d.currentConfigGroup = Array(\"Wallpaper\", \"org.kde.image\", \"General\");d.writeConfig(\"Image\", \"file://" + temp_local_image_location + "\")}'"
        kde_split = shlex.split(kde_command)
        subprocess.Popen(kde_split, stdout=subprocess.PIPE)
    elif "gnome" in os.environ.get('DESKTOP_SESSION'):
        subprocess.Popen(["/usr/bin/gsettings", "set",
                          "org.gnome.desktop.background",
                          "picture-uri", f"'{temp_local_image_location}'"],
                           stdout=subprocess.PIPE)
    else:
        print("Your current desktop environment is unsopported. Please use KDE-plasma or Gnome")
        os.exit(0)

And it also differentiated between the possible browsers/drivers like so (I realise the empty except statement is bad practice and will need to specify later on):

    try:
        desired_capabilities = DesiredCapabilities.CHROME.copy()
        desired_capabilities['connection'] = "keep-alive"
        browser = webdriver.Chrome(desired_capabilities=desired_capabilities)
    except:
        desired_capabilities = DesiredCapabilities.FIREFOX.copy()
        desired_capabilities['connection'] = "keep-alive"
        browser = webdriver.Firefox(desired_capabilities=desired_capabilities)

So I basically need a clean way to check if any of these packages is already installed. And if so, if the corresponding dependencies (e,g, Chrome for chromedriver and Firefox for Geckodriver) for that particular depency is installed.

I'll start by looking into the meta-package solution some more. Will report my progress. Might take a bit of time though, as I am usually short of it like all of us smile

Last edited by Sergy (2020-07-20 21:40:57)

Offline

#7 2020-07-21 03:51:11

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: How to deal with mutuality exclusive opt-depends

eschwartz wrote:
Sergy wrote:

Problem / question: The dependencies needed by the script in order to work properly depend upon wheter the user is running the KDE-plasma or Gnome desktop environment

pacman cannot possibly know which DE the user selects at login time.

So can you clarify if this is actually true?

Because it sounded like you chose between chromedriver and geckodriver based on the DE. Which would means e.g. installing chromedriver does nothing if you are logged into KDE, because the script would only try geckodriver.

Basically, what are the actual requirements for the script, and under which circumstances?


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB