Package Details: xdg-utils-custom-open 1.1.2-4

Git Clone URL: https://aur.archlinux.org/xdg-utils-custom-open.git (read-only, click to copy)
Package Base: xdg-utils-custom-open
Description: Command line tools that assist applications with a variety of desktop integration tasks
Upstream URL: http://www.freedesktop.org/wiki/Software/xdg-utils/
Licenses: MIT
Conflicts: xdg-utils
Provides: xdg-utils
Submitter: jfrankenau
Maintainer: MarsSeed
Last Packager: jfrankenau
Votes: 3
Popularity: 0.29
First Submitted: 2023-06-29 19:15 (UTC)
Last Updated: 2023-06-29 19:15 (UTC)

Required by (834)

Sources (1)

Latest Comments

1 2 Next › Last »

fryfrog commented on 2023-08-08 18:25 (UTC)

@MarsSeed: You don't need to comment on all my packages that should be -bin, I know. Please let me know if you're willing to help convert them. I've emailed you. You can stop spamming me.

MarsSeed commented on 2023-06-29 20:21 (UTC) (edited on 2023-06-29 20:25 (UTC) by MarsSeed)

Thank you, @jfrankenau, for creating this new xdg-utils-custom-open package!

It would be best to mention something in the description about the customizability/replaceability of the original xdg-open script.

MarsSeed commented on 2023-06-27 14:40 (UTC)

Repo's xdg-desktop-portal depends on a virtual xdg-desktop-portal-impl package, and the alternative modules that implement that feature have declared provides=xdg-desktop-portal-impl:

  • xdg-desktop-portal-gtk
  • xdg-desktop-portal-kde
  • xdg-desktop-portal-gnome
  • xdg-desktop-portal-hyprland
  • xdg-desktop-portal-lxqt
  • xdg-desktop-portal-wlr

jfrankenau commented on 2023-06-27 14:40 (UTC)

Thank you both for the ideas. I think that MarsSeed's proposal is the most straightforward solution. I will test it in the next few days and if everything works as expected, update this package accordingly, contact the maintainers of the xdg-open alternatives and document this in the wiki.

MarsSeed commented on 2023-06-27 14:33 (UTC)

My proposal would solve the problem without any metapackages whatsoever. :)

eclairevoyant commented on 2023-06-27 14:29 (UTC)

As long as we don't have 10 different metapackages, either is fine with me :)

MarsSeed commented on 2023-06-27 14:22 (UTC)

@eclairevoyant that could work as well, but doing it the one-metapackage way would mean xdg-utils-no-open cannot declare conflict with xdg-utils, because then it would conflict with the metapackage as well.

MarsSeed commented on 2023-06-27 14:14 (UTC) (edited on 2023-06-29 20:30 (UTC) by MarsSeed)

So here's what I would do:

  • rename xdg-utils-no-open to something like xdg-utils-custom-open
  • make it provide and conflict with xdg-utils
  • make it depend on a virtual package, like xdg-open-impl
  • make the "opener" packages provide xdg-open-impl
  • make the "opener" packages conflict with xdg-open-impl (only 1 can be installed)

Edit 1: plus a necessary fix:

  • make the "opener" packages depend on our renamed xdg-utils-custom-open pkg, ensuring that the openers transitively conflict with repo's xdg-utils (as the openers themselves cannot directly declare conflicts=xdg-utils)

Edit 2: adding important constraint (however self-evident):

  • "opener" packages should under no circumstances declare provides, nor conflicts for xdg-utils

Edit 3: minor adjustments (renamed virtual interface to shorter xdg-open-impl)

What do you think?

eclairevoyant commented on 2023-06-27 14:12 (UTC)

One cleaner solution might be to have 1 metapackage (I'll call it xdg-utils-replacement), that depends on xdg-open and xdg-utils-no-open, and provides xdg-utils (no conflicts needed). Then we ask the xdg-open replacement utilites' maintainers to each provide xdg-open.

MarsSeed commented on 2023-06-27 14:07 (UTC)

@eclairevoyant and @jfrankenau, both of your observations are correct, I see the reason in them.

But as you both are saying, we are stuck with packages relying on xdg-utils via their declared 'depends'.

And there seem to be no golden route to solving the packaging issues with respect to customization of "resource opener".

If we choose to go without metapackages, a lot of combo-named packages could be created, like xdg-utils-linopen, xdg-utils-busking, etc. etc.

Which would entail a lot of parallel maintenance work, as all of them should individually build and package an xdg-utils package without xdg-open, plus declare an xdg-open-provider.

If we go with separate 'umbrella' metapackages, the provides/conflicts mismatches cannot be adequately solved.

But I see a third option - I will elaborate it in my next comment.

1 2 Next › Last »