Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] RFC: ruby-3.1: Debundle gems from the main spell

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] RFC: ruby-3.1: Debundle gems from the main spell
  • Date: Sun, 2 Jul 2023 10:49:23 +0200

Am Sat, 20 Aug 2022 20:25:22 -0400
schrieb Pavel Vinogradov <vin.public AT gmail.com>:

> haven't used ruby in years but I'm all for it. less compile time +
> modularity.

> On Thu, Aug 18, 2022 at 12:33:28PM +0200, Ismael Luceno wrote:
> > In general, with Perl, Ruby, Python, etc., we've had this sort of
> > issue where new modules get added which conflict with our spells,
> >
> > It's always more practical to just disable bundled stuff.

I like being able to rely on things being standard enough to be bundled
with a normal installation of the language runtime. Maybe you already
imply this: Disabling a bundled package followed by depending on the
separate thing. Meaning: When I cast 'perl', I always get the full set
of modules installed that would normally be bundled.

We only need to ensure, then, that on updating the base, all versions
of debundled spells need to be brought up to at least the version that
would have been bundled. How automatic is our tooling for this? How
about cases where the available bundled version trails the base
language release for some reason? Or recognize that independent
development ceased and the bundled version is the only real upstream?

As a general principle … I am hesitant to deviate from our approach not
to deviate from upstream easily. (Or, is that our approach?) I see
that our distro barely exists and thus any deviation puts additional
burden on non-present maintainer time.

I'd like discussions about such things more once we got some heir to
the stable grimoire from this decade, some ISO, whatever. Or … you
know, finally something like my soversion preservation as standard
feature, not nuking the system on toolchain upgrades.

But back to the point: If there is a technical issue for some package,
unbundling can be considered to fix that. But just unbundle it because
we can? More work for us, while deviating from the exact selection of
packaged versions from the upstream bundle. Some things are not meant
to be unbundled.


Alrighty then,

Thomas




Archive powered by MHonArc 2.6.24.

Top of Page