From: ScrelliCopter <ScrelliCopter@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: dumb: Package dumbplay & split libaldmb, take ownership
Date: Fri, 19 Feb 2021 04:06:48 +0100 [thread overview]
Message-ID: <20210219030648.TKCv25G7sNIRWb8zAqfbZmdLsc4igT8tlfRTtQvyCbE@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-28182@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
New comment by ScrelliCopter on void-packages repository
https://github.com/void-linux/void-packages/pull/28182#issuecomment-781782351
Comment:
> Is this package really something you'd use in an environment where allegro4's dependencies aren't already installed? Maybe push all the extras (aldumb and dumbplay) into a single subpackage with all extra deps?
>
> I'm not sure this will receive any updates any more, so it's not going to make maintenance much harder, I'd just prefer to be sure it's not adding to many unnecessary subpackages.
Allegro 4 is ancient and none of the packages in Void's repos that depend on `allegro4` use `dumb` nor its optional Allegro 4 integration. Newer versions of Allegro use DUMB directly and don't rely on this old support library.
I only know of one well-known piece of software; Adventure Game Studio; that uses both Allegro 4 & DUMB, but its DUMB appears to be an ancient 0.9.2 version that is built in-tree rather than being pulled from the distro.
I'll concede that the proposed split is more than a little philosophical rather than purely technical, but I can see an (admittedly extremely rare) case for running dumb and dumbout on a headless server where the chains of X11 & desktop sound server dependencies allegro4 would pull in only serve to add unnecessary bloat. IMO that justifies splitting a seldom used glue library.
>
> Also, please include the rationale you exposed in the PR message in the commit message itself.
Will do on next push.
next prev parent reply other threads:[~2021-02-19 3:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-24 19:32 [PR PATCH] " ScrelliCopter
2021-01-24 20:03 ` ScrelliCopter
2021-02-18 5:03 ` [PR REVIEW] " ericonr
2021-02-18 5:03 ` ericonr
2021-02-19 2:04 ` ScrelliCopter
2021-02-19 2:21 ` ScrelliCopter
2021-02-19 3:06 ` ScrelliCopter [this message]
2021-02-19 3:58 ` ScrelliCopter
2021-02-19 5:01 ` [PR PATCH] [Updated] " ScrelliCopter
2021-02-19 5:02 ` ScrelliCopter
2021-02-24 4:57 ` [PR PATCH] [Merged]: " 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=20210219030648.TKCv25G7sNIRWb8zAqfbZmdLsc4igT8tlfRTtQvyCbE@z \
--to=screllicopter@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).