From mboxrd@z Thu Jan 1 00:00:00 1970 From: swedebugia Subject: Re: Policy to remove obsolete packages Date: Tue, 05 Feb 2019 23:47:26 +0100 Message-ID: References: <20190204100318.208254da@alma-ubu> <87munbkvy8.fsf@gnu.org> <20190205111301.2070ec2d@alma-ubu> <20190205213134.yluu4butrdrcy6uj@uptimegirl.lan> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----QXK26EJH2TS0JF3Q3TKVRSUYPIFHTU" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:33846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gr9VH-0004Oc-6H for guix-devel@gnu.org; Tue, 05 Feb 2019 17:47:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gr9VF-0002zN-Rz for guix-devel@gnu.org; Tue, 05 Feb 2019 17:47:43 -0500 Received: from mx1.riseup.net ([198.252.153.129]:60974) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gr9VE-0002xd-Da for guix-devel@gnu.org; Tue, 05 Feb 2019 17:47:41 -0500 In-Reply-To: <20190205213134.yluu4butrdrcy6uj@uptimegirl.lan> 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, ng0@n0.is ------QXK26EJH2TS0JF3Q3TKVRSUYPIFHTU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ng0@n0=2Eis skrev: (5 februari 2019 22:31:53 CET) >Bjrn Hfling transcribed 846 bytes: >> On Mon, 04 Feb 2019 23:52:47 +0100 >> Ludovic Court=C3=A8s wrote: >>=20 >>=20 >> > (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=2E) >>=20 >> We have guix pull --commit=3D=2E=2E=2E, inferiors, channels and time-tr= avel, >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=2E=20 >Or depending on what your idea of keeping old packages is=2E 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=2E >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=2E > >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=2E >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])=2E That's the gist >of it=2E just have a repository instead of dropping it from a tree=2E >Once it's fixed up in the "wip" repository, move it back into the >main repository=2E >I can elaborate more on this if you want me to once I'm no longer sick=2E > >> Bj=C3=B6rn >>=20 Interesting! I like the idea of keeping it simple and now we tried the lumped modules a= pproach=2E I don't like it so much to be honest=2E It comes with obvious drawbacks when the package per file grow and subcate= gorization have to be done=2E But is it efficient in guile to load hundreds of modules where all pull in= more or less the same dependencies?=20 If yes I think your idea is worthwhile Nils=2E=20 We might have 3 repos: wip, core, extra But switching to one module per package might involve a lot of work=2E Can= we automate it somehow?=20 If yes we will probably end up with a couple thousand modules that import = more modules than necessary=2E E=2Eg=2E it would be no breakage if the spli= t script simply includes all use-module-lines of the parent in the new chil= d modules=2E 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 =2E us= e-modules-lines that are superfluous=2E --=20 Sent from my k-9 mail for Android=2E ------QXK26EJH2TS0JF3Q3TKVRSUYPIFHTU Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
ng0@n0=2Eis skrev: (5 f= ebruari 2019 22:31:53 CET)
Bjrn Hfling transcribed 846 bytes:
On Mon, 04 Feb 2019 23:52:47 +0100
Lu=
dovic Court=C3=A8s <ludo@gnu=2Eorg> wrote:


(Note that, IIUC, in openSuSE a package c=
an be broken and yet remain
installable by users, because the last binar=
y that was produced is
still around=2E)

We have guix=
 pull --commit=3D=2E=2E=2E, inferiors, channels and time-travel, so
ther=
e are plenty opportunities to keep old states :-)

There=
 are many ways to keep it, but they are really sometimes just jumping throu=
gh too many hoops=2E 
Or depending on what your idea of keeping old pack=
ages is=2E it should be easy, but
it involves a good amount[1] of work t=
o build a much older version
with the otherwise almost-only recent,updat=
ing,master=2E
To the point where you have to do the logical thing and lo=
ok into
which versions upstream or guix build around that time as depend=
encies
and simply "freeze" all the dependencies in your package=2E
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 work=
s:

a year or 2 back i experimented with a complete resructure of Gui=
x,
and packages got split up differently (one module per package mostly)=

leading to different kinds of problems and fixes=2E
a separate repos=
itory 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])=2E That's the gist
of it=2E just have a repository=
 instead of dropping it from a tree=2E
Once it's fixed up in the "wip" r=
epository, move it back into the
main repository=2E
I can elaborate m=
ore on this if you want me to once I'm no longer sick=2E

Bj=C3=B6rn




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

It comes with obvious drawba= cks when the package per file grow and subcategorization have to be done=2E=

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 ide= a is worthwhile Nils=2E

We might have 3 repos: wip, core, extra
=
But switching to one module per package might involve a lot of work=2E = Can we automate it somehow?
If yes we will probably end up with a coupl= e thousand modules that import more modules than necessary=2E E=2Eg=2E it w= ould be no breakage if the split script simply includes all use-module-line= s of the parent in the new child modules=2E

Could we use an AI to he= lp find unneded use-modules afterwards? Maybe just a half intelligent one t= hat tries removing them one by one and sees if the derivation is computed c= orrectly and report back a pairs of modules =2E use-modules-lines that are = superfluous=2E
--
Sent from my k-9 mail for Android=2E
------QXK26EJH2TS0JF3Q3TKVRSUYPIFHTU--