From: lane-brain <lane-brain@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [Package Request] XDEB .deb to .xbps converter
Date: Sun, 06 Dec 2020 22:24:56 +0100 [thread overview]
Message-ID: <20201206212456.dFHwOIvgktDdiNmopJbvTGNCmGQb0HDM2Hc3MhrimGg@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-26981@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]
New comment by lane-brain on void-packages repository
https://github.com/void-linux/void-packages/issues/26981#issuecomment-739566417
Comment:
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.
next prev parent reply other threads:[~2020-12-06 21:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-06 8:42 [ISSUE] " xanadu3
2020-12-06 13:17 ` Duncaen
2020-12-06 16:06 ` nativepapaya
2020-12-06 17:21 ` xanadu3
2020-12-06 18:22 ` nativepapaya
2020-12-06 20:45 ` jrigg
2020-12-06 20:47 ` jrigg
2020-12-06 21:20 ` xanadu3
2020-12-06 21:24 ` lane-brain
2020-12-06 21:24 ` lane-brain [this message]
2020-12-06 22:29 ` jrigg
2020-12-07 0:41 ` xanadu3
2020-12-07 2:05 ` hippi777
2020-12-07 2:08 ` hippi777
2021-01-01 16:19 ` glaulher
2021-01-21 17:39 ` ericonr
2021-01-21 17:39 ` [ISSUE] [CLOSED] " ericonr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201206212456.dFHwOIvgktDdiNmopJbvTGNCmGQb0HDM2Hc3MhrimGg@z \
--to=lane-brain@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).