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: 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] Any progress on not blindly breaking the system on updates?
  • Date: Sun, 5 Apr 2020 16:27:51 +0200

On 05/Apr/2020 10:02, Thomas Orgis wrote:
> 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?

Oh... I guess I didn't write all my thoughts down XD.

I meant the manual tracking of dependency versions is too much work, and
we have no proper feature for it (but I recently added a nice helper to
FUNCTIONS that is an approximation).

Also, I think we should make a few changes w.r.t. how selection happens
in Sorcery so that it can actually choose spells from a secondary
grimoire if a newer version is needed and available.

We can't afford the current layered system, so maybe we need to extend
the spell versioning with a release tag so that you don't automatically
pull in spells from a newer release, and then basically look for the
newest spells within a release tag.

> > 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.

Agreed, but our written rules must match what we do.

> > 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.

I looked into it and I'm not convinced we can use pkgsrc as a backend,
nor that it's a good idea.

First because it's option systems and binary packages have exactly the
same problems ours have. Second, Makefiles are as bad as shell scripts.

However, we can take ideas an features, of course, and maybe even
have a tool to import packages.

Let's face it, the problem is the idea of Source Mage is attractive
to a very small population, and on top of that we break too much and
even when it works it takes too much work.

But it isn't a chicken and egg problem; we just need tools that
automatically enforce quality controls, and tools that ease the most
repetitive tasks, like finding new versions for upgrades.

> 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?

I mean to use DESTDIR instead of hacks.

For 90% of packages it just works, and for the rest we could provide a
replacement for chmod (and install) that replays the changes, or we can
fix the spell or install it manually, whatever is easier.

> > - 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.

Yes, when copying DSOs we can scan them. Problem is where and how to
store this data. I would prefer it to be reliable but easy to deal with.

> 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.

Well, that's my idea, we do some analysis over the staging, so that we
can track the DSO dependency chains.

Removal tool would take the list of files to remove and exclude those
still needed, then queue them for later removal by cleanse.




Archive powered by MHonArc 2.6.24.

Top of Page