I've just finished the pcre deprecation change [1].
If anyone is interested, please take a look.

[1] https://fedoraproject.org/wiki/PcreDeprecation

Lukas

On Wed, Aug 17, 2022 at 2:43 PM Lukas Javorsky <ljavo...@redhat.com> wrote:

> Hi Richard,
>
> The Fedora 39 System Wide changes are scheduled for Jun 2023, so that
> would be the deadline for this.
>
> However, after feedback, I've decided to create a pcre deprecation change
> at first so it's broken into more pieces and it's better documented.
> When it's ready, I'll paste the link for the new pcre deprecation change.
> You can ignore the retirement change for now, because that one will be
> proposed after the package is deprecated.
>
> Thank you and sorry for the inconvenience.
> Lukas
>
> On Wed, Aug 17, 2022 at 2:33 PM Richard W.M. Jones <rjo...@redhat.com>
> wrote:
>
>> On Wed, Aug 17, 2022 at 02:25:06PM +0200, Lukas Javorsky wrote:
>> > The Fedora change for this topic is created [1].
>> >
>> > [1] https://fedoraproject.org/wiki/PcreRetirement
>>
>> It would be helpful to have an actual deadline written in there.
>> "Fedora 39" requires an indirection.  Are we talking 2023?  2024?
>> What date exactly?  I need to tell upstreams that they have until a
>> certain date to make the change.
>>
>> Rich.
>>
>> > On Mon, Aug 15, 2022 at 11:46 AM Lukas Javorsky <ljavo...@redhat.com>
>> wrote:
>> >
>> >     Hi,
>> >
>> >     I've decided to write a Fedora change that will contain all of the
>> >     information about this possible retirement.
>> >
>> >     I have to fill the dependencies that will be affected by this
>> change, so
>> >     I'm looking for the tool/command which will give them to me.
>> >     I've seen multiple suggestions here in this thread, but is there
>> some kind
>> >     of consensus about which one should I choose (which one is the most
>> >     accurate)?
>> >
>> >     Thank you so much
>> >     Lukas
>> >
>> >     On Tue, Jul 26, 2022 at 11:17 AM Paolo Bonzini <pbonz...@redhat.com>
>> wrote:
>> >
>> >         Due to static linking, not all functions will be included in the
>> >         executable and therefore some simple "hello world"  binaries
>> will not
>> >         need sysprof-capture-static. However, anything that used the
>> .pc file
>> >         will need it.
>> >
>> >         Technically, you could also use glib's static library without
>> dependent
>> >         .a libraries if you link with glib's .a file but do not specify
>> >         -static; but that's not a good argument against having a
>> Requires for
>> >         the dependency in my opinion, because it makes the .pc file not
>> work
>> >         out of the box. Perhaps a weak dependency, but even that sounds
>> >         strange.
>> >
>> >         As to glibc-static I think it's fair to say that whoever uses
>> -static
>> >         will have to install it on their own, so it can be left out of
>> >         glib2.spec.
>> >
>> >         Paolo
>> >
>> >
>> >         Il mar 26 lug 2022, 10:59 Daniel P. Berrangé <
>> berra...@redhat.com> ha
>> >         scritto:
>> >
>> >             Although listed in glib-2.0.pc, I didn't find any need for
>> the
>> >             sysprof-capture-static package, but it does need
>> glibc-static
>> >
>> >         _______________________________________________
>> >         devel mailing list -- devel@lists.fedoraproject.org
>> >         To unsubscribe send an email to
>> devel-le...@lists.fedoraproject.org
>> >         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@lists.fedoraproject.org
>> >         Do not reply to spam on the list, report it: https://pagure.io/
>> >         fedora-infrastructure
>> >
>> >
>> >
>> >     --
>> >     S pozdravom/ Best regards
>> >
>> >     Lukáš Javorský
>> >
>> >     Software Engineer, Core service - Databases
>> >
>> >     Red Hat
>> >
>> >     Purkyňova 115 (TPB-C)
>> >
>> >     612 00 Brno - Královo Pole
>> >
>> >     ljavo...@redhat.com
>> >
>> >     [logo--200]
>> >
>> >
>> >
>> >
>> >
>> > --
>> > S pozdravom/ Best regards
>> >
>> > Lukáš Javorský
>> >
>> > Software Engineer, Core service - Databases
>> >
>> > Red Hat
>> >
>> > Purkyňova 115 (TPB-C)
>> >
>> > 612 00 Brno - Královo Pole
>> >
>> > ljavo...@redhat.com
>> >
>> > [logo--200]
>> >
>> >
>>
>> --
>> Richard Jones, Virtualization Group, Red Hat
>> http://people.redhat.com/~rjones
>> Read my programming and virtualization blog: http://rwmj.wordpress.com
>> virt-builder quickly builds VMs from scratch
>> http://libguestfs.org/virt-builder.1.html
>>
>>
>
> --
> S pozdravom/ Best regards
>
> Lukáš Javorský
>
> Software Engineer, Core service - Databases
>
> Red Hat <https://www.redhat.com>
>
> Purkyňova 115 (TPB-C)
>
> 612 00 Brno - Královo Pole
>
> ljavo...@redhat.com
> <https://www.redhat.com>
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat <https://www.redhat.com>

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com
<https://www.redhat.com>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to