guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Policy to remove obsolete packages


From: swedebugia
Subject: Re: Policy to remove obsolete packages
Date: Tue, 05 Feb 2019 23:47:26 +0100

address@hidden skrev: (5 februari 2019 22:31:53 CET)
Bjrn Hfling transcribed 846 bytes:
On Mon, 04 Feb 2019 23:52:47 +0100
Ludovic Courtès <address@hidden> wrote:


(Note that, IIUC, in openSuSE a package can be broken and yet remain
installable by users, because the last binary that was produced is
still around.)

We have guix pull --commit=..., inferiors, channels and time-travel, so
there are plenty opportunities to keep old states :-)

There are many ways to keep it, but they are really sometimes just jumping through too many hoops.
Or depending on what your idea of keeping old packages is. it should be easy, but
it involves a good amount[1] of work to build a much older version
with the otherwise almost-only recent,updating,master.
To the point where you have to do the logical thing and look into
which versions upstream or guix build around that time as dependencies
and simply "freeze" all the dependencies in your package.

1: amount depending on what you are building

There are other ways to handle obsolete packages, but I think they
don't map to how guix works:

a year or 2 back i experimented with a complete resructure of Guix,
and packages got split up differently (one module per package mostly)
leading to different kinds of problems and fixes.
a separate repository with the prefix -wip holds all the unstable,
obsolete, unfinished, etc packagesi (remotely comparable to how
ports trees are handled, but not quiet like it[1]). That's the gist
of it. just have a repository instead of dropping it from a tree.
Once it's fixed up in the "wip" repository, move it back into the
main repository.
I can elaborate more on this if you want me to once I'm no longer sick.

Björn





Interesting!
I like the idea of keeping it simple and now we tried the lumped modules approach. I don't like it so much to be honest.

It comes with obvious drawbacks when the package per file grow and subcategorization have to be done.

But is it efficient in guile to load hundreds of modules where all pull in more or less the same dependencies?

If yes I think your idea is worthwhile Nils.

We might have 3 repos: wip, core, extra

But switching to one module per package might involve a lot of work. Can we automate it somehow?
If yes we will probably end up with a couple thousand modules that import more modules than necessary. E.g. it would be no breakage if the split script simply includes all use-module-lines of the parent in the new child modules.

Could we use an AI to help find unneded use-modules afterwards? Maybe just a half intelligent one that tries removing them one by one and sees if the derivation is computed correctly and report back a pairs of modules . use-modules-lines that are superfluous.
--
Sent from my k-9 mail for Android.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]