From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0@n0.is Subject: Re: Policy to remove obsolete packages Date: Tue, 5 Feb 2019 23:52:34 +0000 Message-ID: <20190205235216.jc5phlh7zkgdg5ey@uptimegirl.lan> References: <20190204100318.208254da@alma-ubu> <87munbkvy8.fsf@gnu.org> <20190205111301.2070ec2d@alma-ubu> <20190205213134.yluu4butrdrcy6uj@uptimegirl.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:46763) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grAWO-0007sC-2C for guix-devel@gnu.org; Tue, 05 Feb 2019 18:52:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1grAWM-0002mf-5u for guix-devel@gnu.org; Tue, 05 Feb 2019 18:52:55 -0500 Received: from aibo.runbox.com ([91.220.196.211]:41050) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1grAWL-0002js-SQ for guix-devel@gnu.org; Tue, 05 Feb 2019 18:52:54 -0500 Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1grAWJ-0003Hi-HQ for guix-devel@gnu.org; Wed, 06 Feb 2019 00:52:51 +0100 Received: by mailfront12.runbox.com with esmtpsa (uid:892961 ) (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) id 1grAW3-0006dz-OR for guix-devel@gnu.org; Wed, 06 Feb 2019 00:52:36 +0100 Content-Disposition: inline In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org swedebugia transcribed 6.9K bytes: > ng0@n0.is 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 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. (just aside: I prefer ng0) > 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. my experiments (with guix) predated the current discussion on reorganzing parts of it, so take it with a grain of salt. I can not link to my layout (eventually I will get to write about it, ideas moved on, ideas developed from this) here for reasons of material not allowed in GuixSD. The gist at the time before I stopped the work, was to create a very small guix core, extendable through plugins by users, a templating system for system configurations and all sorts of things I don't want to explain now. packages were split into some essential core packages (given a very minimal server or some other factors, this can not be separated from core) inside "guix" and a bigger collection of everything else in "ports". This went through some itterations, got a bunch of new packages I never managed to send back (and fixes which should make their way into guix.. we had an functional Nim for example, no idea if someone fixed it in guix master in the last year), and ports followed this abbreviated style: . bin/ ~doc ~etc ports/ ports/$category ports/patches ports/$category/$name/$name.scm AUTHORS CHANGELOG LEGAL LICENSE MOVED TODO UPDATING config.mk Makefile ports.scm etc.. the category/name part was mostly so that I could have deeper nestings for languages, python variants, variants in general, and so forth. it was just an itteration of ideas in the beginning. categories were largely arbitrary when they weren't cross-compared to pkgsrc, ports, portage and others. I can't really say if this would help with the layout guix has because I went through great length dissecting that. At the time I had some ideas growing, and some established, and wanted to see how they could scuplture/terraform guix. I think the one-module thing was discussed before in guix but I did not follow it at the time. The 'freezing DAGs' (sort of) is still something I'm thinking about, but with additional ideas came additional thoughts about languages and requirements, leading away from Guix. if you do let's call it technically incorrect "collision detection" for such a large collection manually you want automation as much as possible, as you pointed out. just take it as some rambling about very detailed notes I have made but not in the well-furbished format that I'd publish them on my website and 50% or so still on (physical) paper,.. > -- > Sent from my k-9 mail for Android.