Summary: | [TRACKER] dev-scheme/guile-1.8.x should be dropped | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Austin English (RETIRED) <wizardedit> |
Component: | Current packages | Assignee: | Scheme Project <scheme> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | arthur, gentoo.wayne, pacho, soap |
Priority: | Normal | Keywords: | PMASKED, Tracker |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=590558 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 436400, 590558, 538592, 577630, 590536, 590800, 590802, 590804, 590806, 590808, 590810, 590812, 590814, 590816, 590818, 590820, 590822, 590824, 590826, 592084, 613984, 654654, 693290 | ||
Bug Blocks: | 682392 | ||
Attachments: | ebuilds with old guile |
Description
Austin English (RETIRED)
2016-06-27 16:20:22 UTC
Hi, my free time is very limited, each time I 've tried to work on this, I've stuck in this bloody list of crappy reverse dependencies. I'll try build a testbox and work in the next weeks on this problem. I think amynka and others have tried to solve this too, don't know how far they have gotten, need to read all bugs again. The other way is to just drop guile-1.8 together with all reverse deps that don't work with guile-2 and get over this mess once and for all. Slotting sucks, I should have done it 3-4 years ago when fulax's eselect code was in play, now I I think it's a waste of time. If anyone wants to step up and do it, I have no objections, just try not to make things worse. Autogen and make are the packages that should always work because some base-system packages need it. Eg guile used to be needed when gcc was built with FEATURES=test because it pulled in autogen, don't know what happens now, have to check. We can change this to a tracker bug then to follow all the bugs related with the reverse deps that will break with guile-2 and handle them more easily I have fixed a few of these bugs. I have left some open (more specifically IN_PROGRESS) when they were stable for some arches prior to my fixes. I assumed we don't want to blindly carry those stable flags forward without adequate testing. You have a choice of closing those now or after stabilization. general question: lilypond's devs say it's going to be "1-2 years" before lilypond will run with guile-2.* (iiuc there's something with the guile code itself that is causing lily to puke). I use(d) lilypond as one of my main tools; as it is broken with guile-2.*, what should I do in the meantime? side note: I'm devaway and don't know the full status of guile in the tree. @Andrew: one of the main reasons I didn't push guile-2 in the tree myself 3-4 years ago, was lilypond. But we have waited too long. Amynka finally had the courage to start this task. To my point of view, everything with guile-1 should be dropped or fixed. I don't know how other distros handle lilypond but we can't keep the dinosaur guile just for a package. Upstream must be pushed to fix lilypond asap, or bundle it somehow if licensing accepts it. I'll try do some testing if I find spare time. I'm sorry we're causing this to you. (In reply to N. Andrew Walsh from comment #4) > general question: lilypond's devs say it's going to be "1-2 years" before > lilypond will run with guile-2.* (iiuc there's something with the guile code > itself that is causing lily to puke). I use(d) lilypond as one of my main > tools; as it is broken with guile-2.*, what should I do in the meantime? I am sorry but you have incorrect information. The problem is not in guile but in lilypond. We however don't know why upstream was not able to patch lilypond so far but I believe they will or someone else will do it. Solution for you is to still use old guile which will not be removed till the upstream of lilypond don't fix their problems. Cheers, Amy (In reply to Amy Winston from comment #6) > (In reply to N. Andrew Walsh from comment #4) > > general question: lilypond's devs say it's going to be "1-2 years" before > > lilypond will run with guile-2.* (iiuc there's something with the guile code > > itself that is causing lily to puke). I use(d) lilypond as one of my main > > tools; as it is broken with guile-2.*, what should I do in the meantime? > > I am sorry but you have incorrect information. The problem is not in guile > but in lilypond. We however don't know why upstream was not able to patch > lilypond so far but I believe they will or someone else will do it. > Solution for you is to still use old guile which will not be removed till > the upstream of lilypond don't fix their problems. > > Cheers, > Amy Since I think lilypond is the only package still not ported to guile-2... if you still want to keep in the tree, I would try to create a guile-1.8 slot only for that one in the way Fedora is doing (I mean, the main version without playing with the names of the files to not collide would be guile-2, while the "renamed one" guile-1.8). http://pkgs.fedoraproject.org/cgit/rpms/compat-guile18.git/tree/compat-guile18.spec Otherwise, lilypond users will stil be in trouble as other guile reverse deps will try to install guile-2 (In reply to Pacho Ramos from comment #7) > (In reply to Amy Winston from comment #6) > > (In reply to N. Andrew Walsh from comment #4) > > > general question: lilypond's devs say it's going to be "1-2 years" before > > > lilypond will run with guile-2.* (iiuc there's something with the guile code > > > itself that is causing lily to puke). I use(d) lilypond as one of my main > > > tools; as it is broken with guile-2.*, what should I do in the meantime? > > > > I am sorry but you have incorrect information. The problem is not in guile > > but in lilypond. We however don't know why upstream was not able to patch > > lilypond so far but I believe they will or someone else will do it. > > Solution for you is to still use old guile which will not be removed till > > the upstream of lilypond don't fix their problems. > > > > Cheers, > > Amy > > Since I think lilypond is the only package still not ported to guile-2... if > you still want to keep in the tree, I would try to create a guile-1.8 slot > only for that one in the way Fedora is doing (I mean, the main version > without playing with the names of the files to not collide would be guile-2, > while the "renamed one" guile-1.8). > http://pkgs.fedoraproject.org/cgit/rpms/compat-guile18.git/tree/compat- > guile18.spec > > Otherwise, lilypond users will stil be in trouble as other guile reverse > deps will try to install guile-2 We will probably slot the guile anyways working on it right now. (In reply to Amy Winston from comment #8) > > We will probably slot the guile anyways working on it right now. Any news on this? I think texmacs will also need the old 1.8 slot :/ (In reply to Pacho Ramos from comment #9) > (In reply to Amy Winston from comment #8) > > > > We will probably slot the guile anyways working on it right now. > > > Any news on this? I think texmacs will also need the old 1.8 slot :/ I am working on texmacs but it can also happen that we will have to slot it eventually. I am working on solution. commit e09fe196a13f2faa4b184b1bf5d7f961c4c8b8b0 Author: Matt Turner <mattst88@gentoo.org> Date: Sun Sep 1 12:16:42 2019 -0700 profiles: Mask dev-scheme/guile < 2 and app-office/texmacs Bug: https://bugs.gentoo.org/436400 Signed-off-by: Matt Turner <mattst88@gentoo.org> I see `USE=guile2` is now forced for lilypond since Sep. 1st, 2019. guile2 cripples lilypond to the point of uselessness. "compiles without errors" is about the only positive thing that can be said about that combination. lilypond developers still have lots of work to do to finish their port to guile2, they are aware of it and I know, we've been waiting for years. Above in this report was a discussion of either slotting guile1 or bundling lilypond with guile1, but it appears those two points were ignored when decision to force guile2 was made. Does that mean gentoo will drop lilypond next and that I should copy the guile1 and lilypond ebuilds to my local overlay if I want to keep using a functional lilypond? |