GTK 2 removal from RHEL 10+

[Tomáš Popela]

Hi everyone,

This is an early heads-up about GTK 2 removal from RHEL 10+ (the gtk2
package was marked as unwanted in ELN with
https://github.com/minimization/content-resolver-input/commit/b6d44e496f4...).
The toolkit served us gratefully, but it starts to show its age with
regards to modern technologies such as Wayland, HiDPI screens, HDR and
others.

In RHEL 10 the GTK 3 and GTK 4 will still continue to be available for
everyone to use.

Regards,

Tom Popela

-- 

Tomáš Popela

Desktop and Desktop Applications Subsystems Product Owner

Display Systems

Red Hat

[Kevin Kofler]

Tomáš Popela wrote:
>  This is an early heads-up about GTK 2 removal from RHEL 10+ (the
> gtk2
>  package was marked as unwanted in ELN with
>
> https://github.com/minimization/content-resolver-input/commit/b6d44e496f4...).
I suppose it could be carried in EPEL if needed. Or is somebody attempting 
to veto that too?

        Kevin Kofler

[Sérgio Basto]

On Sat, 2022-08-27 at 01:44 +0200, Kevin Kofler via devel wrote:
>  Tomáš Popela wrote:
>  > This is an early heads-up about GTK 2 removal from RHEL 10+ (the
>  > gtk2
>  > package was marked as unwanted in ELN with
>  >
> https://github.com/minimization/content-resolver-input/commit/b6d44e496f4...
>  > ).
>  
>  I suppose it could be carried in EPEL if needed. Or is somebody
>  attempting 
>  to veto that too?
>   
Finally I got this idea , we should have the *archived packages group*,
that can be excluded from mass rebuild and gcc and python updates etc .
The rest of the idea is instead force the retirement of the package we
move it to the archive group , and by default archive group is not used
, but if any one need a library to run an obsoleted applications he can
.   

As Kevin Kofler (more or less) wrote in "Pcre Deprecation" thread,
maybe we should be prepared to support pcre-1 forever and IMO we also
can extend the concept to other packages, btw GTK2 is one of them .


Checking on rawhide gtk2 still have 385 packages that depend on gtk2
... 



-- 
Sérgio M. B.

[Tomáš Popela]

Hi Sérgio,

Dne so 27. 8. 2022 21:53 uživatel Sérgio Basto <sergio(a)serjux.com&gt; napsal:

>  As Kevin Kofler (more or less) wrote in "Pcre Deprecation"
> thread,
>  maybe we should be prepared to support pcre-1 forever and IMO we also
>  can extend the concept to other packages, btw GTK2 is one of them .
>
>
>  Checking on rawhide gtk2 still have 385 packages that depend on gtk2
>  ... 

Please don't mix apple and oranges - the email is about RHEL and not about
Fedora. We don't have any intentions for removing GTK 2 from Fedora (at
least not for the foreseeable future) and even if that would happen, we
would orphan the package so anyone from the community can step in.

Bye,
Tom

[Nico Kadel-Garcia]

On Mon, Aug 29, 2022 at 2:05 AM Tomáš Popela <tpopela(a)redhat.com&gt; wrote:
>  Hi Sérgio,
>
>  Dne so 27. 8. 2022 21:53 uživatel Sérgio Basto <sergio(a)serjux.com&gt; napsal:
> >
> > As Kevin Kofler (more or less) wrote in "Pcre Deprecation" thread,
> > maybe we should be prepared to support pcre-1 forever and IMO we also
> > can extend the concept to other packages, btw GTK2 is one of them .
> >
> >
> > Checking on rawhide gtk2 still have 385 packages that depend on gtk2
> > ...
>
>
>  Please don't mix apple and oranges - the email is about RHEL and not about Fedora. We
> don't have any intentions for removing GTK 2 from Fedora (at least not for the
> foreseeable future) and even if that would happen, we would orphan the package so anyone
> from the community can step in.
>
>  Bye,
>  Tom 
Since that orange grows in the apple orange, and since RHEL is based
on Fedora, it seems a reasonable concern. We just had this with
python2 and python3, which is still messy.

[Tomáš Popela]

Hi Kevin,

Dne so 27. 8. 2022 1:44 uživatel Kevin Kofler via devel <
devel(a)lists.fedoraproject.org&gt; napsal:

>  Tomáš Popela wrote:
>  > This is an early heads-up about GTK 2 removal from RHEL 10+ (the gtk2
>  > package was marked as unwanted in ELN with
>  >
>
> https://github.com/minimization/content-resolver-input/commit/b6d44e496f4...
>  ).
>
>  I suppose it could be carried in EPEL if needed. 

Yes, definitely someone can come in and package it in EPEL if they want to.

Or is somebody attempting
>  to veto that too?
>  
I don't see why anyone would do that.

Bye,
Tom