sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] RFC: ruby-3.1: Debundle gems from the main spell
- From: Ismael Luceno <ismael AT iodev.co.uk>
- To: Thomas Orgis <thomas-forum AT orgis.org>
- Cc: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] RFC: ruby-3.1: Debundle gems from the main spell
- Date: Tue, 4 Jul 2023 16:04:15 +0200
This discussion dead for quite a while :-/.
On 02/Jul/2023 10:49, Thomas Orgis wrote:
> 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.
I didn't think too much about that, but it's a valid concern, perhaps
to avoid confusions yet allow minimal install, it should be split
between the language core components, and a metapackage for the
standard install, that way we get the best of both worlds.
> 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?
Pretty manual, but we can just make it a requirement for splitting, and
the implementation shouldn't be too complicated.
> 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?
That's rarely the case, but if they're forking the module and don't
provide a separate repo/tarball, we can just use the main tarball for
that and install it separately, generally all it takes is to fill
some template (if it isn't included already).
> 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.
Upstreams used to be sensible, except perhaps perl and a few others,
but that isn't true anymore. In any case, almost every piece of code
out there is including it's requirements and often even recomends
installing on a virtual environment, so this won't make things worse.
> 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.
Yes, we need to discuss this as well, I think we need that and we need
to make updates to the toolchain installable in parallel like Debian
does, to add some extra safety.
> 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.
Bundling is a bad practice, most of the time this produces problems,
and you end up with newer versions installed on the system anyway,
which take precedence... I don't see debundling as a step backwards,
but we could do something to ensure compatible versions...
-
Re: [SM-Discuss] RFC: ruby-3.1: Debundle gems from the main spell,
Thomas Orgis, 07/02/2023
- Re: [SM-Discuss] RFC: ruby-3.1: Debundle gems from the main spell, Ismael Luceno, 07/04/2023
Archive powered by MHonArc 2.6.24.