| Message ID | 20191024192056.5428-1-h.goebel@crazy-compilers.com |
|---|---|
| Headers | show |
On Thu, Oct 24, 2019 at 09:20:56PM +0200, Hartmut Goebel wrote: > The monolithic `qt` package was only used as a base to inhert `qt-4` from. > > For testing this change does not change qt-4 in any way: > - run ./pre-inst-env guix build qt@4.8.7 > - apply patch > - again run ./pre-inst-env guix build qt@4.8.7 > > -> qt@4.8.7 will *not* be build again. To avoid any rebuilds, I even refrined > from sorting the inputs. :-) > > The other patch removes a package which has been merged into qtdeclarative as > of Qt 5.8.0 and is not used anywhere. > > > Hartmut Goebel (2): > gnu: Remove qtdeclarative-render2d. > gnu: Remove monolithic qt5. > > gnu/packages/qt.scm | 328 +++++++------------------------------------- > 1 file changed, 49 insertions(+), 279 deletions(-) > On qtdeclarative-render2d, I think the only reason to possibly keep it is Debian old-stable (or old-old stable, not sure) packaged the 5.7 series, but I don't think they even used it for anything. Very much vote yes on monolithic qt-5.
On Fri, Oct 25, 2019 at 01:34:49PM +0300, Efraim Flashner wrote: > On Thu, Oct 24, 2019 at 09:20:56PM +0200, Hartmut Goebel wrote: > > The monolithic `qt` package was only used as a base to inhert `qt-4` from. > > > > For testing this change does not change qt-4 in any way: > > - run ./pre-inst-env guix build qt@4.8.7 > > - apply patch > > - again run ./pre-inst-env guix build qt@4.8.7 > > > > -> qt@4.8.7 will *not* be build again. To avoid any rebuilds, I even refrined > > from sorting the inputs. :-) > > > > The other patch removes a package which has been merged into qtdeclarative as > > of Qt 5.8.0 and is not used anywhere. > > > > > > Hartmut Goebel (2): > > gnu: Remove qtdeclarative-render2d. > > gnu: Remove monolithic qt5. > > > > gnu/packages/qt.scm | 328 +++++++------------------------------------- > > 1 file changed, 49 insertions(+), 279 deletions(-) > > > > On qtdeclarative-render2d, I think the only reason to possibly keep it > is Debian old-stable (or old-old stable, not sure) packaged the 5.7 > series, but I don't think they even used it for anything. > > Very much vote yes on monolithic qt-5. > Actually, we should probably depreciate it and mark it superseded by qtbase for a while. Packages in channels won't have it ripped out, but if/when they fail to build they'll find out that its modular qt only now.
Hello, Efraim Flashner <efraim@flashner.co.il> skribis: > On Fri, Oct 25, 2019 at 01:34:49PM +0300, Efraim Flashner wrote: [...] >> Very much vote yes on monolithic qt-5. >> > > Actually, we should probably depreciate it and mark it superseded by > qtbase for a while. Yeah, I think we should do that and remove in one or two months. (We can also use ‘define-deprecated’ for the variable itself, like I did for ‘guile-json’, to make sure channel authors notice.) Thanks, Ludo’.
Hi, Efraim Flashner <efraim@flashner.co.il> wrote: > On qtdeclarative-render2d, I think the only reason to possibly keep it > is Debian old-stable (or old-old stable, not sure) packaged the 5.7 > series, but I don't think they even used it for anything. We don't have any qt 5.7 package anymore and this package is deprecated since long. I'm in favor of removing it. Am 25.10.19 um 23:33 schrieb Ludovic Courtès: >> Actually, we should probably depreciate it and mark it superseded by >> qtbase for a while. > Yeah, I think we should do that and remove in one or two months. (We > can also use ‘define-deprecated’ for the variable itself, like I did for > ‘guile-json’, to make sure channel authors notice.) Okay for me. But I don't understand how to use ‘define-deprecated’. Documentations says: "Define a deprecated variable or procedure, along these lines: (define-deprecated foo bar 42) (define-deprecated (baz x y) qux (qux y x)) And for guile json it is: (define-deprecated guile-json guile-json-1 guile-json-1) Given this, I have *no* clue how to use this function. can anybody please explain?!
Hi Hartmut, > Am 25.10.19 um 23:33 schrieb Ludovic Courtès: > >>> Actually, we should probably depreciate it and mark it superseded by >>> qtbase for a while. >> Yeah, I think we should do that and remove in one or two months. (We >> can also use ‘define-deprecated’ for the variable itself, like I did for >> ‘guile-json’, to make sure channel authors notice.) > > Okay for me. > > But I don't understand how to use ‘define-deprecated’. If you write: (define-deprecated qt qtbase qtbase) then every user of variable ‘qt’ will get a warning saying that ‘qt’ is deprecated and that they should use ‘qtbase’ instead; furthermore, ‘qt’ will be an alias for ‘qtbase’ (which is maybe not a great idea.) HTH! Ludo’.