Hello Rex,
>So, we (kde-sign, Qt maintainers) generally update strategically where it
>makes sense to warrant the time investment in doing so.
I understand.
Also that some people contribute it in their free time/or paid time
(but not mandatory to contribute),
which of course means a lot.
I understand that packaging is a fairly time consuming task.
Back in the days when I used openSUSE and OBS I built the Unity
desktop environment
and maintained it a release and a half IIRC (30+ packages where some
require custom vendor patches),
different from what the distribution (gnome, the patches) uses.
Another contributor chenxialong packaged it at that time for Fedora on OBS
from the same repository (because doing something more sophisticated
than (cross) build a simple package
is not possible using Fedora tools, but todays requirements are) so a
lot of the packaging effort was shared.
As (re)build takes some time it is nice to edit some things (spec
files) from the web interface,
on your phone from the gym or on another computer very easily possible
in OBS. I think that
something similar would attract people to contribute to the packaging
in Fedora in general.
>Bumping Qt versions is... a fairly difficult process in fedora,
>unfortunately.
I understand, but there are some things that concern me.
I would like to use secure Qt (5.14) with all security critical fixes
(and new functions) built for Fedora.
As a User of Fedora I would like to contribute and others to
contribute as a packager but
I do not see tools that provide the minimum requirements to do so.
(a Web Interface for spec file editing, multiple repos e.g for Qt).
As a Linux enthusiast I am deeply concerned with a far better (and
long term easier to maintain)
technical solution being suppressed either by incapable management, "I
just work there" mentality
or people who prefer to spend hours of work they are used too instead
of 5 minutes work that's new for them
(reminds me of systemd somehow).
>Bumping Qt versions is... a fairly difficult process in fedora,
>unfortunately.
Introducing a new Qt version could be very simple I think:
1) Branch all Qt related packages (it should be with a one line
command or using a web interface)
2) Edit package version number (with a per project (like Qt:5.14.1
project) macro - 1 digit changed/or two)
3) Wait for packages to be published into repo (and that repo contains
all packages - without spec change - that use Qt priv headers).
4) Fix eventual build failures due to re based patches etc.
5) optional: Press push to start a request to get this merged into main repo.
>Bumping Qt versions is... a fairly difficult process in fedora,
>unfortunately.
Would a workflow similar to the one described allow speed up providing
the newest Qt optionally in let's say
qt5.14/x86_64/{rawhide, f32, f31. f30} but keeping the main repo
unchanged if desired?
Would you say that the current build system maybe needs improving or a
rework to provide kde-sign, Qt maintainers and you
you with a slightly less difficult process?
Would you agree that having the possibility for users to choose a
different Qt version from a different versioned repo
may help testing and improve quality?
Would you and the kde-sign, Qt maintainers say that the workflow
described above maybe is exactly what is needed (OBS)?
Br,
Damian
On Wed, Jan 29, 2020 at 6:32 PM Rex Dieter <rdieter@xxxxxxxxxxxx> wrote:
>
> Damian Ivanov wrote:
>
> > But it's not the only CVE fixed with Qt 5.14.1
> > The point is that there is other software using Qt which doesn't start
> > with K even though K works just fine with 5.14 by the experience of other
> > distributions.
>
> Bumping Qt versions is... a fairly difficult process in fedora,
> unfortunately. The primary reason is that there are many packages that use
> Qt private api's the require rebuilding for every release. Quick check just
> now in rawhide is that a full Qt5 version update requires (re)building at
> least 78 packages.
>
> So, we (kde-sign, Qt maintainers) generally update strategically where it
> makes sense to warrant the time investment in doing so.
>
> -- Rex
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
