[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'core-updates' Q4 2019
From: |
Kei Kebreau |
Subject: |
Re: 'core-updates' Q4 2019 |
Date: |
Fri, 22 Nov 2019 21:11:51 -0500 |
User-agent: |
Evolution 3.32.4 |
Hello again Miguel,
I apologize for the delay. My semester at university is becoming
busier as final exams get closer!
On Fri, 2019-11-08 at 01:58 +0100, Miguel Arruga Vivas wrote:
> Hi Kei,
...
> > > - The patch for gedit contains a reference to libgd, wouldn't it
> > > be
> > > clearer for the reader/updater to have it defined in a let
> > > over
> > > the package definition and use the name in native-inputs?
> > >
> >
> > I'm not sure. I don't know if there is an explicit convention for
> > packaging software that is distributed like this, and the examples
> > of
> > this in the code base (that I've seen, at least) define the
> > third-party library the way I've done it here. I'm open to change
> > on
> > this point though.
>
> This actually should have been an open question, as I have a patch on
> libosinfo, related with gnome-boxes (patches coming soon) and it
> doesn't feel right for me having usb.ids and pci.ids hidden there, so
> I've put another origin needed (osinfo-db) out there.
>
After some thought, I believe it is clearer to someone reading the
package to see the origin object defined in the "native-inputs" field
rather than a let over the whole package. The extra "let" adds a layer
of indirection in reading the code that I'm not sure pays off. Also,
such a bound variable could be accessed both directly and through the
"native-inputs" field, so that could be confusing as well.
> > > - Is there any reason to not patch-out the gtk-icon-update-cache
> > > invocations? If I understand it correctly, this is performed
> > > at
> > > profile level, so makes no sense creating a cache at package
> > > level, isn't it? The patches for quadrapassel, gnome-klotski,
> > > ghex,
> > > gnome-sudoku, gnome-mines, five-or-more and gedit contain
> > > references to it. Maybe creating a package like
> > > xorg-server-for-tests (perhaps 'gtk-bin-for-build'?) linked to
> > > "true" from coreutils would help in the long term.
> > >
> >
> > I don't think such a reason exists. I could add changes that
> > substitute calls to "gtk-icon-update-cache" with "true" for these
> > packages, but I agree that a better solution may be possible.
> > Perhaps not a package; maybe a new 'patch-gtk-icon-update-cache'
> > phase in the relevant build systems?
>
> Some of these packages already have phases for it on master. I
> rebased
> your branch onto it (1a9df94cec..fb936351d3), I had to solve two
> merge
> conflicts: devhelp and totem.
>
> devhelp's patch has only a trivial conflict, as there was no
> arguments
> parameter before. OTOH, I did not check as much as I should totem's
> last day, as now I have one question here: Who kills the Xvfb server
> on display :1 after the tests? I see it's a common idiom, but I
> don't
> get why shouldn't the daemon treat it like from any other process and
> wait for it to reach completion (other than technical means, I mean).
> This could be a great place for a #:xorg-for-tests?, should I try?
>
I really like the idea of an #:xorg-for-tests? flag! If you can
attempt a patch, I'll do my best to help.
> > > As a final comment, the gnome release cycle and the amount of
> > > packages involved is quite big, so again, thank you.
> > >
> > > Happy hacking!
> > > Miguel
> >
> > Thanks Miguel! This comment and review means a lot!
> > Kei
>
> Thank you too
>
> Best regards,
> Miguel