[Package Request] XDEB .deb to .xbps converter

[xanadu3]

XDEB successfully converts .deb packages into a .xbps package and an x86_64-repodata file.

https://github.com/toluschr/xdeb

[Duncaen]

Adding this to the repository feels like some sort of endorsement, I don't think this is a good idea.

[nativepapaya]

Personally, it might be better to instead request the deb package that you would like to see in void rather than relying on tools like these.

[xanadu3]

Indeed it would be better to have all these packages I'd wish to have in an official repository, supervised by official Void developers, but most of them are not redistributable and some of them are open source but hard to compile. Some examples:

• Master PDF Editor 4.3.89 (the last free version with full functionality)
• ProtonMail Bridge 1.5.2 (now open source – but as far as I know depending on some non-free Qt component – maybe I'm wrong)
• Sublime Text Dev 4094
• The closed source VS Code
• Ubuntu Audio Recorder

I converted them with XDEB and they work perfectly. Of course this is just a quick an dirty solution, but because of this I was able to migrate from Artix runit to Void. The AUR is quite handy in such cases, although of questionable security :D

For CrossOver, I decided to install it in my user folder instead of systemwide, using the official generic installer.

What do you think about that?

[jrigg]

It's fairly easy to extract files from .deb packages with 'ar x package.deb' and install them manually, eg. in /usr/local or ~/. I've done this on a couple of occasions when I needed a quick and dirty solution, but I wouldn't be comfortable with an application that installed 'foreign' package files in the same places as official Void pkgs.

[xanadu3]

It's fairly easy to extract files from .deb packages with 'ar x package.deb' and install them manually, eg. in /usr/local or ~/. I've done this on a couple of occasions when I needed a quick and dirty solution, but I wouldn't be comfortable with an application that installed 'foreign' package files in the same places as official Void pkgs.

XDEB doesn't install anything. It unpacks a .deb and packs it as a .xbps. After that it has to be installed with xbps-install. Personally, I don't like unpacking .debs and installing their content manually, since uninstalling or updating afterwards is quite inconvenient. Actually, XDEB does a very similar thing as xbps-src does e.g. with discord.

[lane-core]

It's a reality that proprietary software will tend to target Ubuntu, but I'm also aware that proprietary software isn't void's focus. I'm sympathetic for this use case however, there happens to be a template for bitwig studio that uses the ar x method @jrigg described.

I think that xdeb did something useful, which was write the script that extracts the dependencies and converts them to their xbps equivalents. I'm looking over the script just to see exactly how xdeb constructs the package. It would appear that it simply installs everything into their target directories as dpkg would; so installing alongside the official xbps package file targets. I also don't think that's a good idea.

What I think would be great is if instead of spitting out a full package, a parser like this generates a package template with the dependencies and other package info filled in, and leaves it to the maintainer to make whatever tweaks needed. A tool like that should be included.

Because it's for the most part individual applications you would have to install this way I believe that these packages should live in their own folders in /opt with a launch script placed in bin, which is currently what the bitwig package does. But it's worthwhile to have a larger conversation, because since this is a common enough use case it would be worthwhile to establish conventions about opt packages.

[jrigg]

XDEB doesn't install anything. It unpacks a .deb and packs it as a .xbps. After that it has to be installed with xbps-install.

Which I presume will install the files in /usr, not /usr/local or /opt. That's the part I don't like.

[xanadu3]

@lane-brain and @jrigg – I agree that a conversion without an adaptation of the folder structure and other distro specific details is not a good idea. I tried XDEB also with steam and in this case the autoconverted package broke my system. :D

It would be great if XDEB could be the starting point of a toolkit for the (semi) automatic creation of template files. Void is very charming on the desktop and even if "proprietary software isn't void's focus", it is often quite hard to live without it. Arch solved the problem with the toolchain around AUR, the PKGBUILD files and makepkg. In my opinion, it would be great if Void had something similar: A repository of template files, integrated into OctoXBPS.

(BTW: The ProtonMail Bridge e.g. is distributed in three formats: DEB, RPM and PKGBUILD. Wouldn't it be marvellous if they provided also an XBPS template file?)

[hippi777]

hi folks! :)

i saw other distros' package managers in void, i see them as they are nice-to-have toys for making void a swiss army knife when it comes to hack on broken systems or for experimenting with whatever weird ideas and what not... :D i feel the same about xdeb! it can be used to experiment around debian stuffs while i guess xbps will track the files of the packages created by xdeb, and that renders it less of a dirty work.

other than this to my campaign for it, i guess its basically a matter of 1-2 lines inside the docs, that it exists, it is related to void, and therefore included for quick-and-dirty hacking purposes, however it is discouraged, and basically a package request is the way to go.

also, i think it should be improved, it has active maintenance, u can address the maintainer of it with requests, that is the option for creating an initial/"good enough" template, and it should get a way to prefix the path, and then it can install things under /usr/local or home, or even a chroot test environment! :)

(dont forget to) have fun on hacking! ;) (... i mean in general, and just to keep the right spirit! :D )

[glaulher]

there is apt in void, does not answer?

[ericonr]

Unpacking debian packages isn't something we recommend, which is what adding the tools to the official repositories would mean. Closing.