Announcing libkiwix soversion bump
by Vitaly Zaitsev
Hello all.
libkiwix 12.0.0 will include a soversion bump from .11 to .12.
I will take care of all dependent packages.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1 year, 5 months
Orphaned gtkhtml3
by Milan Crha
Hi there,
I just orphaned gtkhtml3 [1]. It used to be used by Evolution many
years ago. It's unmaintained and archived upstream since Evolution
moved to the WebKitGTK.
The only user of it is xiphos, whose maintainer I added to the CC. They
can take it, if they want to.
Bye,
Milan
[1] https://src.fedoraproject.org/rpms/gtkhtml3
1 year, 5 months
F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by
macro (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Perl_replace_MODULE_COMPAT_by_macro
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
A ''perl(:MODULE_COMPAT_%(eval "<nowiki>`%{__perl}
-V:version`</nowiki>"; echo $version))'' run-time dependency will be
replaced with a new ''%perl_require_compat'' macro in all Perl spec
files.
The macro will expand differently based on architecture specificity of
the binary packages. That will significantly shrink an amount of Perl
packages required to be rebuilt with each Perl upgrade.
== Owner ==
* Name: [[User:jplesnik| Jitka Plesnikova]]
* Email: <jplesnik(a)redhat.com>
=== Completed items ===
=== Items in progress ===
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F38
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F37
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F36
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F35
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in RHEL 9
* Update [[Packaging:Perl | Fedora Packaging Guidelines for Perl]]
* Replace ''perl(:MODULE_COMPAT_XXX)'' by `%perl_require_compat`
run-time in all F38 spec files (3259)
== Detailed Description ==
The list of packages that need to be rebuilt with the new major
version of Perl is determined according to the dependency on
''perl(:MODULE_COMPAT_XXX)'' now.
In Fedora, all Perl modules run-require the versioned
''perl(:MODULE_COMPAT_XXX)'' provided by ''perl-libs'' now.
However, only multi-arch packages need to have a dependency on the
particular version of Perl it was built against, or on a newer version
of Perl that provides backward compatibility with it. For those
packages, we need to ensure that the packages will use the right
version of ''libperl.so'' for the Perl used during the rebuild.
The noarch packages don't need to be rebuilt against each new major
version of Perl, they only have to require non-versioned ''perl-libs''
which includes all directories used by all Perl modules.
The macro ''%perl_require_compat'' will evaluate the run-require based
on ''%{_target_cpu}''. The macro will be defined in the rpm
''perl-srpm-macros'' and the definition is:
`%perl_require_compat %[ "%{_target_cpu}" == "noarch" ? "perl-libs" :
"%{!?perl_version:perl-libs}%{?perl_version:perl(:MODULE_COMPAT_%{perl_version})}"
]`
The macro ''%perl_requires_compat'' will evaluate to the correct
value. There is a known, yet harmless, imperfection: The macro will
evaluate to ''perl(:MODULE_COMPAT_XXX)'' even in noarch subpackages of
a multi-arch main package. In this case, I recommend to use `Requires:
%perl_require_compat`. The purpose of the change is a matter of
simplifying the rebuild, where it depends if the source package
produces at least one multi-arch binary package. Not on whether it
makes a noarch subpackage next to it.
If you don't want to see this imperfection you could use directly
`Requires: perl-libs`.
The macro will work for all supported Fedoras and EPEL 9.
For EPEL 8 and older, it won't work, because the
[https://rpm-software-management.github.io/rpm/manual/macros.html
Expression Expansion] is not implemented there. In these versions,
''perl(:MODULE_COMPAT_%(eval "<nowiki>`%{__perl}
-V:version`</nowiki>"; echo $version))'' must be used.
== Benefit to Fedora ==
It will simplify the rebuild and reduce the number of packages which
have to be rebuild from 3259 to approximately 600. It should currently
be enough to rebuild only multi-arch packages and those that are part
of the Perl itself (dual-life packages). Here we need to ensure that
the packages will use the right ''libperl.so'' for the Perl used. The
new syntax will also be shorter and clearer for packagers.
== Scope ==
* Proposal owners:
** Submit Fedora Packaging Guidelines for Perl update to Fedora
Packaging Committee.
** Update and rebuild perl-srpm-macros source package.
** Add ''%perl_require_compat'' to ''perl-srpm-macros'' package in
older Fedoras.
** Replace Requires for ''perl(:MODULE_COMPAT_XXX)'' with
''%perl_require_compat'' in all spec files.
* Other developers: Get familiar with new Fedora Packaging Guidelines for Perl.
* Release engineering: No action needed.
[https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A (not needed for this Change) <!--
REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated
for this feature? If so, does it need to happen before or after the
implementation is done? If a FPC ticket exists, add a link here.
Please submit a pull request with the proposed changes before
submitting your Change proposal. -->
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
N/A
== How To Test ==
All multi-arch packages which use the macro should run-require
''perl(:MODULE_COMPAT_%{perl_version})'' and the ''noarch'' packages
should run-require ''perl-libs'' except the case listed in '''Detailed
Description'''.
== User Experience ==
There should not be any remarkable change in user experience.
== Dependencies ==
This change will affect 3259 source packages and all binary noarch
packages. The rebuild of affected packages will be done by mass
rebuild of Fedora 38. There is no dependency on other Fedora changes.
== Contingency Plan ==
* Contingency mechanism: The change will be reverted.
* Contingency deadline: Before Mass Rebuild.
* Blocks release? No.
== Documentation ==
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 5 months
Should the policy documents better reflect real package maintenance
practice?
by Gordon Messmer
In the wild, I often see Fedora described as a "semi-rolling" release.
As a policy matter, the distribution promises to be mostly stable, but I
find it increasingly hard to honestly present it as such.
As a couple of quick examples, I'd point out that in Fedora 35, Blender
updated from 2.93 (an LTS version) to version 3. In Fedora 36, Emacs
updated from version 27 to 28. I've read in the KDE Matrix channel that
KDE will be updated in Fedora 36 to 5.26, even though it has already
been updated from 5.24 -> 5.25 (my reading of the KDE update policy is
that Fedora used to update all releases with every KDE release, but
decided to stop). Firefox and Thunderbird get updates in most releases,
even when they contain API-breaking changes (those really should have
an explicit exception, IMHO.) I could offer more, but my point is
simply that examples of updates in prominent packages isn't hard to find.
That's not necessarily to object to those changes (though I did have to
do some minor fixes after the emacs update, and I grumbled quietly), and
I don't want to disrupt users getting new features if that's what
everyone actually wants. But, it does bother me that the documentation
doesn't seem to reflect reality. I think that the documentation should
offer users a realistic expectation of what they'll get from Fedora.
Does anyone else feel like the documentation should be updated, or am I
making too much of this?
1 year, 5 months
