Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Any progress on not blindly breaking the system on updates?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: Ismael Luceno <ismael AT iodev.co.uk>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Any progress on not blindly breaking the system on updates?
  • Date: Sun, 5 Apr 2020 10:02:24 +0200

Am Sun, 5 Apr 2020 01:01:47 +0200
schrieb Ismael Luceno <ismael AT iodev.co.uk>:

> Not only this would not be enough, it also does not scale. The problem
> is that a fix that scales means making incompatible changes.

What exactly does not scale? You mean the list of abandoned SOVERSIONS?

> In order to fix some of these problems we need to change our policies.

I don't see much to do around policies without people acting on those.
I think we are at a place where when somebody has an idea and actually
time to work on it, that somebody can just do it and wait for dissent,
which needs to be backed up with willingness and time to do it better.

> Regarding dependencies, we need to enforce version checks at least, and
> we need to test the supported versions somehow.

More work? Well, pkgsrc does that. Dependency rules take version
incompatibility information from the current version of a package in
the repository (>=$abi_version) and update that package, too, if the
installed version does not qualify. That would be a smarter variant of
`cast -Z`. Somebody has to write these rules, though. A kind of
automatic cleanse run checking symbols could help.

Yeah, pkgsrc is rather strict about storing which files a package is
supposed to install (PLIST). This is hard to maintain with options and
different platforms, may be simpler for SMGL as it's one platform, but
it's harder as we have more options. Thinking further, one could store
the symbols installed libraries provide and sound an alarm if a symbol
or library soversion goes missing (or is not present yet in the
installed version). A rough heuristic for the obvious incompatibilties.
Then you need to tune that heuristic not to fire on internal binaries
and libs that only the spell itself uses …

> I want to change following things about sorcery:
>
> - unprivileged build

+1

> - mandatory staged install w/o sorcery support

Explain please. What do you mean with sorcery support here?

> - installation and removal helpers should automatically protect DSOs and
> track outdated binaries for replacement

Sure, that would be nice. You mean that our tooling does the work from
the staging area to the main system, right? Yes, that would be sane and
it's embarrassing that it's not the case yet. Again, pkgsrc manages
that (installs into DESTDIR and builds/installs a binary package from
that) since ages, using nothing fancy like a FUSE filesystem. It seems
to be all wrapper binaries that isolate anything that runs shell
commands to do things.

Got time to write our better version of it? ;-)

I'm serious, though. When I see the easy hack that fixes the worst
breaks, I'm very much tempted to implement it, at least as an option,
until the proper reworking arrives. The good enough vs. the perfect and
all that.


Alrighty then,

Thomas




Archive powered by MHonArc 2.6.24.

Top of Page