Fedora Modular 27 compose report: 20171104.n.2 changes
by Fedora Branched Report
OLD: Fedora-Modular-27-20171104.n.0
NEW: Fedora-Modular-27-20171104.n.2
===== SUMMARY =====
Added images: 0
Dropped images: 0
Added packages: 0
Dropped packages: 15
Upgraded packages: 15
Downgraded packages: 2
Size of added packages: 0.00 B
Size of dropped packages: 25.42 MiB
Size of upgraded packages: 46.97 MiB
Size of downgraded packages: 4.94 MiB
Size change of upgraded packages: -184.00 B
Size change of downgraded packages: -4.79 KiB
===== ADDED IMAGES =====
===== DROPPED IMAGES =====
===== ADDED PACKAGES =====
===== DROPPED PACKAGES =====
Package: authconfig-7.0.1-4.module_fa897d0f
Summary: Command line tool for setting up authentication from network services
RPMs: authconfig
Size: 1626388 bytes
Package: autogen-5.18.12-5.module_fa897d0f
Summary: Automated text file generator
RPMs: autogen autogen-libopts autogen-libopts-devel
Size: 5239168 bytes
Package: babel-2.3.4-6.module_fa897d0f
Summary: Tools for internationalizing Python applications
RPMs: babel babel-doc python2-babel python3-babel
Size: 10518368 bytes
Package: custodia-0.5.0-9.module_fa897d0f
Summary: A service to manage, retrieve and store secrets for other processes
RPMs: custodia python2-custodia python2-custodia-extra python3-custodia python3-custodia-extra
Size: 286016 bytes
Package: fontawesome-fonts-4.7.0-3.module_fa897d0f
Summary: Iconic font set
RPMs: fontawesome-fonts fontawesome-fonts-web
Size: 643952 bytes
Package: hesiod-3.2.1-9.module_fa897d0f
Summary: Shared libraries for querying the Hesiod naming service
RPMs: hesiod hesiod-devel
Size: 432516 bytes
Package: m2crypto-0.27.0-1.module_fa897d0f
Summary: Support for using OpenSSL in python scripts
RPMs: m2crypto
Size: 2173420 bytes
Package: oddjob-0.34.4-3.module_fa897d0f
Summary: A D-Bus service which runs odd jobs on behalf of client applications
RPMs: oddjob oddjob-mkhomedir
Size: 903968 bytes
Package: python-jinja2-2.9.6-2.module_fa897d0f
Summary: General purpose template engine
RPMs: python2-jinja2 python3-jinja2
Size: 1122460 bytes
Package: python-markupsafe-0.23-16.module_fa897d0f
Summary: Implements a XML/HTML/XHTML Markup safe string for Python
RPMs: python2-markupsafe python3-markupsafe
Size: 526116 bytes
Package: python-yubico-1.3.2-7.module_fa897d0f
Summary: Pure-python library for interacting with Yubikeys
RPMs: python2-yubico python3-yubico
Size: 125480 bytes
Package: pytz-2017.2-2.module_fa897d0f
Summary: World Timezone Definitions for Python
RPMs: python3-pytz pytz
Size: 106144 bytes
Package: pyusb-1.0.0-5.module_fa897d0f
Summary: Python bindings for libusb
RPMs: python3-pyusb pyusb
Size: 174912 bytes
Package: rolekit-0.5.2-1.module_fa897d0f
Summary: A server daemon with D-Bus interface providing a server roles
RPMs: rolekit
Size: 143840 bytes
Package: softhsm-2.2.0-2.module_fa897d0f.2
Summary: Software version of a PKCS#11 Hardware Security Module
RPMs: softhsm softhsm-devel
Size: 2629120 bytes
===== UPGRADED PACKAGES =====
Package: autofs-1:5.1.3-4.module_6cf16c42
Old package: autofs-1:5.1.3-4.module_fa897d0f
Summary: A tool for automatically mounting and unmounting filesystems
RPMs: autofs
Size: 5494424 bytes
Size change: -20 bytes
Package: bind-dyndb-ldap-11.1-6.module_6cf16c42
Old package: bind-dyndb-ldap-11.1-6.module_fa897d0f
Summary: LDAP back-end plug-in for BIND
RPMs: bind-dyndb-ldap
Size: 913260 bytes
Size change: 56 bytes
Package: freeipa-4.6.1-3.module_6cf16c42
Old package: freeipa-4.6.1-3.module_fa897d0f
Summary: The Identity, Policy and Audit system
RPMs: freeipa-client freeipa-client-common freeipa-common freeipa-python-compat freeipa-server freeipa-server-common freeipa-server-dns freeipa-server-trust-ad python2-ipaclient python2-ipalib python2-ipaserver python2-ipatests python3-ipaclient python3-ipalib python3-ipaserver python3-ipatests
Size: 13350724 bytes
Size change: -288 bytes
Package: freeipa-desktop-profile-0.0.6-1.module_6cf16c42
Old package: freeipa-desktop-profile-0.0.6-1.module_fa897d0f
Summary: FleetCommander integration with FreeIPA
RPMs: freeipa-desktop-profile
Size: 39168 bytes
Size change: -48 bytes
Package: gssntlmssp-0.7.0-5.module_6cf16c42
Old package: gssntlmssp-0.7.0-5.module_fa897d0f
Summary: GSSAPI NTLMSSP Mechanism
RPMs: gssntlmssp gssntlmssp-devel
Size: 517388 bytes
Size change: 4 bytes
Package: ldns-1.7.0-7.module_6cf16c42
Old package: ldns-1.7.0-7.module_fa897d0f
Summary: Low-level DNS(SEC) library with API
RPMs: ldns ldns-devel ldns-doc ldns-utils perl-ldns python-ldns
Size: 8907488 bytes
Size change: -68 bytes
Package: libica-3.2.0-1.module_6cf16c42
Old package: libica-3.2.0-1.module_fa897d0f
Summary: Library for accessing ICA hardware crypto on IBM z Systems
RPMs: libica libica-devel
Size: 135028 bytes
Size change: -4 bytes
Package: mod_lookup_identity-1.0.0-4.module_6cf16c42
Old package: mod_lookup_identity-1.0.0-4.module_fa897d0f
Summary: Apache module to retrieve additional information about the authenticated user
RPMs: mod_lookup_identity
Size: 209972 bytes
Size change: -16 bytes
Package: ntp-4.2.8p10-3.module_6cf16c42
Old package: ntp-4.2.8p10-3.module_fa897d0f
Summary: The NTP daemon and utilities
RPMs: ntp ntp-doc ntp-perl ntpdate sntp
Size: 7453356 bytes
Size change: 116 bytes
Package: open-sans-fonts-1.10-6.module_6cf16c42
Old package: open-sans-fonts-1.10-6.module_fa897d0f
Summary: Open Sans is a humanist sans-serif typeface designed by Steve Matteson
RPMs: open-sans-fonts
Size: 492244 bytes
Size change: 64 bytes
Package: opencryptoki-3.7.0-3.module_6cf16c42
Old package: opencryptoki-3.7.0-3.module_fa897d0f
Summary: Implementation of the PKCS#11 (Cryptoki) specification v2.11
RPMs: opencryptoki opencryptoki-ccatok opencryptoki-devel opencryptoki-ep11tok opencryptoki-icatok opencryptoki-icsftok opencryptoki-libs opencryptoki-swtok opencryptoki-tpmtok
Size: 5989732 bytes
Size change: 148 bytes
Package: opendnssec-1.4.9-7.module_6cf16c42
Old package: opendnssec-1.4.9-7.module_fa897d0f
Summary: DNSSEC key and zone management software
RPMs: opendnssec
Size: 3258740 bytes
Size change: -100 bytes
Package: python-ldap-2.4.25-6.module_6cf16c42
Old package: python-ldap-2.4.25-6.module_fa897d0f
Summary: An object-oriented API to access LDAP directory servers
RPMs: python-ldap
Size: 1248072 bytes
Size change: -40 bytes
Package: python-lesscpy-0.10.1-10.module_6cf16c42
Old package: python-lesscpy-0.10.1-10.module_fa897d0f
Summary: Lesscss compiler
RPMs: python-lesscpy python3-lesscpy
Size: 178040 bytes
Size change: 0 bytes
Package: slapi-nis-0.56.1-4.module_6cf16c42
Old package: slapi-nis-0.56.1-4.module_fa897d0f
Summary: NIS Server and Schema Compatibility plugins for Directory Server
RPMs: slapi-nis
Size: 1060824 bytes
Size change: 12 bytes
===== DOWNGRADED PACKAGES =====
Package: certmonger-0.79.5-1.module_6cf16c42
Old package: certmonger-0.79.5-2.module_fa897d0f
Summary: Certificate status monitor and PKI enrollment client
RPMs: certmonger
Size: 4648696 bytes
Size change: -276 bytes
Package: mod_auth_gssapi-1.5.1-3.module_6cf16c42
Old package: mod_auth_gssapi-1.5.1-6.module_fa897d0f
Summary: A GSSAPI Authentication module for Apache
RPMs: mod_auth_gssapi
Size: 534196 bytes
Size change: -4632 bytes
6 years, 7 months
Re: Goal: Increased Modularity?
by Les Mikesell
Nicolas Mailhot wrote:
>>> I want to know the correct JAVA_HOME and PATH settings for all the
>>> possible JVMs when they are installed as alternatives-conforming RPM
>>> packages but are not the system default. Is this documented somewhere?
>> It seems the current convention is to put the JAVA packages
>> under /usr/lib/jvm/(java|jre)-<majversion>-<vendor>-<majminversion> with
>> certain packages going to /usr/lib/jvm-exports/
>> and /usr/lib/jvm-private/
>>
>> Who's convention is this, anyway?
>
> Originally, mine when I was active @jpp and was packaging jvms
>
>> And what's it called?
>
> You know, you're the first person to ask this question I know of:)
>
> The layout and its intent is described in the jpackage-1.5-policy
> document shipped with jpackage utils. IIRC I wrote this file a week
> after baking the layout and the associated shell scripts, so that would
> date its definition around March 10, 2003.
>
> I never thought of giving it a name. Today that would be JPackage
> conventions for most people.
So, where do I find the answer to the question above regarding the
correct JAVA_HOME and PATH to use a JVM that is not the system default?
How is the split exports/private directory supposed to relate to that?
>> It seems Fedora
>> and jpackage both honor this convention (and alternatives uses it. Or
>> maybe it's the other way around ... this convention uses was designed
>> around alternatives).
>
> Fedora Java packaging as it's known today is a JPackage fork
> (periodically rebased). The Red Hat Java group originally started from
> its own package repository IIRC, but struggled to package the Java world
> and decided later to use a JPackage base as its repo was more complete.
And what's the current situation with this now that Fedora and RHEL5
include some stuff that looks jpackage'd but isn't? How do you
control, for example, which tomcat version you install?
--
Les Mikesell
lesmikesell(a)gmail.com
16 years, 9 months
Re: [Modularity] A proposal for stream naming
by Matthew Miller
On Thu, Jun 29, 2017 at 08:25:59PM +0200, Brian Exelbierd wrote:
> Does this mean that a module built primarilly from a single application
> does not have a 13 month fixed lifecycle? I hope this is true because,
> in my mind, one of the things a module is promising is that some form of
> API/ABI won't break. When I hear Apache-2.4, I think, "this module is
> apache 2.4. I don't need to know the z-release because I know the 2.4
> API won't be broken." I also think that having an arbitrary EOL for the
> stream of 13 months even though Apache 2.4.x will continue to be
> available after that is odd. What changed causing the need to EOL the
> stream I was on and replace it with a new Apache-2.4 stream? Have I
> just misunderstood modules?
I think it's likely that we would want an Apache 2.4 module to have a
longer-than-13-month-lifecycle. However, I don't want to commit to that
right now. This is actually a good argument for allowing EOL changes.
:)
> > So far, easy, I think. But what about modules like mine which are
> > collections of stuff? We could give them an arbitrary version and
[...]
> What is changing from one collection version to the next? What is my
> understanding of what is in the box at any moment in time? If the
> module is tied to a specific host/platform then I would expect it to
> carry that information in the metadata (see below). If it isn't, what
> change prompts a new version? I think that is what we need to define as
> well.
Different versions of the various programs included may have changes to
command line parameters, big changes to output, etc. One command may
even need to be retired and possibly replaced with another. Having
versioned streams allows people to expect that they can use a certain
toolset without these surprises *inside* that stream.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 12 months
Re: Modularity and all the things
by Matthew Miller
On Tue, Nov 05, 2019 at 04:34:55PM +0000, Jeremy Cline wrote:
> I'd just like to say that I have found this thread very demoralizing. I
> think Randy has valid points and has brought them up far more
> respectfully than I could and I feel like it's being dismissed as
> trolling. I think this has a very negative affect on people's
> willingness to put their opinions out there and is going to lead to an
> echo chamber.
It's definitely gone of the rails, and I'm sorry. I didn't mean for that to
happen. I want to hear people's opinions even if they're dissenting.
But, I still am having a hard time seeing the thing I quoted as a respectful
approach. I avoided paraphrasing before, but I'm going to now, not to
caricature what Randy said but to clarify how it sounds to me and what I'm
reacting to. The message in entirety was:
I've pointed out a few times that other distros have solved the "too
fast, too slow" problem. In at least one case, as long ago as 2004. I
see it as a solved problem and I don't understand why we are trying to
solve it again.
To, that isn't "hey, maybe you missed an elegant prior art we could adapt".
To me, it seems to say "this effort is a waste of time -- this problem is
already solved".
And mentioning "as long ago as 2004" seems ... well, like I said,
inflammatory.
This is not a respectful way to say this to the people who have put a lot of
*years* into working on this problem and solving it in Fedora. Even if we
take as given that other distros have solved the problem for their users, it
being solved _there_ doesn't directly help us _here_. The work people did to
get us to where we are now _does_.
That's what I take objection to, not the suggestion of additional ideas to
move us forward.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
4 years, 7 months
Re: [Modularity] Module streams with two different, non-overlapping,
package sets?
by Stephen Gallagher
On Wed, Jun 20, 2018 at 10:06 AM Mikolaj Izdebski <mizdebsk(a)redhat.com>
wrote:
> On 06/20/2018 02:30 PM, Petr Šabata wrote:
> > Parallel installation of streams on a single system indeed
> > isn't supported at this point and isn't planned anytime in the
> > near future. In general it's a more complicated problem than
> > it might seem at first.
>
> Could you elaborate and explain what's so complicated about it?
>
The short answer is that there exists no generic solution for
parallel-installation. Many packages rely on well-known resources[1] and
cannot be parallel-installed at all. Other packages *may* support
parallel-installation but consumers must take special steps to enable
support for it.
I don't have a good link right now, but folks at Red Hat did a number of
customer studies and determined that in real-world deployments,
parallel-installation was very rarely used. Generally, the OS was
established with a standard set of packages and then anything that needed
an alternate version was deployed as a VM or container.
So, when we started looking at ways to provide alternative software, we
determined that parallel-installation was a non-goal. Not needing to solve
an unsolvable problem meant that we could focus on the parts that really
matter: allowing people to select which single version of the software
meets their needs.
[1] I can't install two packages that try to serve the same well-known
D-BUS name or both provide a local DNS cache, for example. I can't install
two packages that both own the same executable name without using the
"alternatives" system. I can't install two versions of a package that
provide a shared object plugin with the same name. And so on and so forth.
All of these have possible solutions, but no single generic solution
exists. In the general case, we figure that the triumvirate of modules,
containers and VMs solves this problem for 99% of cases. The remaining
exception cases have to be dealt with individually.
6 years
Re: finding recursive builddeps
by Petr Šabata
On Sun, Nov 15, 2020 at 4:13 PM Jason Edgecombe <jason(a)rampaginggeek.com> wrote:
>
> Hi everyone,
>
> I want to rebuild some of the fedora 33 packages for EL8 (vagrant, for example), but I'm having trouble getting all of the build dependencies right. I ran dnf to download the SRPMS with the --resolve option, but I'm still missing dependencies when I submit the builds to copr.
>
> My current workflow is to download an RPM from Fedora 33, then submit it to copr to build on the EPEL8 image in my personal COPR projects, waiting for any library errors, then download those and build, repeat as needed.
>
> That workflow is tedious and I feel like there must be a better way, but I don't know what that is. How can I recursively find all of the builddeps for packages?
>
> Ideally, I would like some type of (semi-)automated way to track packages on Fedora and automatically build them on EL8, but I'm at a loss for how to do so.
>
> Thanks,
> Jason
That is a common [bootstrapping] problem, yes.
In short, you need to query the SRPM & RPM dependencies and their
runtime and build time dependencies, recursively. You also need to do
that on every architecture (due to the potential use of conditional
build deps), so your process should involve SRPM rebuilds as the ones
you download from Fedora repos have only been built on one; and it's
random -- there's a chance you won't be able to resolve your tree if
you use those. Binary RPMs are already available for all arches so you
just need to fetch the repodata.
You can do all this on a single host and arch, don't worry. No uploads
and actual RPM builds are necessary.
Once you have your package list, just compare it to your target
distribution's package list and you have your set.
It's no longer maintained and it was rather quirky buy could try
depchase; it did exactly this when we were experimenting with fully
modular distributions:
https://github.com/fedora-modularity/depchase
P
3 years, 7 months
Re: Modularity and all the things
by Kevin Kofler
Stephen Gallagher wrote:
> By all means, if there are user experience problems, highlight those. Just
> don't draw the conclusion that the whole system is unsalvageable. Let the
> team that's working on it figure out if there's a way to fix the UX or if
> it truly does mean that a structural flaw exists in the design. The
> Modularity Team is reading these threads and is keeping notes on all of
> the legitimate issues raised. As of right now, we don't feel that the
> situation is unrecoverable.
>
> Please keep your suggestions constructive. Tell us where we are falling
> short. We are listening. We're just not ready to throw away years of work
> because it isn't perfect yet. If we did that every time, we'd never get
> anywhere. We wouldn't have taken projects like systemd, KDE 4,
> NetworkManager, and GNOME 3 from their rocky starts to where they are now.
> All of those examples were hard-fought changes that brought considerable
> instability to Fedora when they initially landed and now are cornerstones
> of the Fedora story.
You are pointing out here only those major transitions that ultimately
succeeded after a bumpy start. But you are filtering away the much less
successful examples, such as (and yes, those are mostly upstream decisions,
but so were KDE 4 and GNOME 3 that you used as "good" examples):
* Akonadi, the backend behind the current KMail. In KDE 3 and early KDE 4
times, we used to have KMail 1, a fast and reliable mail program. Then,
during the KDE 4 phase (actually, it was initially planned for KDE 4.0,
but then delayed for several releases due to all sorts of issues with it),
upstream designed a new backend called Akonadi and made KMail use it,
calling the new version KMail 2. Unlike KMail 1 (which they discontinued),
KMail 2 was extremely slow and buggy. I and others pointed out several
inherent design flaws in Akonadi that are the source of both the poor
performance and the unreliability. Upstream refused to listen, never
accepted the reality that Akonadi was unsalvageable, and kept releasing
new "fixed" versions that were not noticeably faster or less buggy. To
this day, KMail still uses Akonadi and is still infamous for its poor
performance and bugginess. Most users switched to non-KDE alternatives
such as Thunderbird, Evolution, Trojitá (which is Qt-based) or web mail
clients. (E.g., I use Trojitá now.) Some even abandoned KDE Plasma
entirely due to Akonadi.
* software getting replaced again and again because the new, better software
turned out not to be all that great after all. The main example I can
think of is the hardware detection layer, where we have had, in
chronological order:
- Kudzu
- HAL
- DeviceKit (and udev, taking over some of its tasks already)
- the "u* stack": udev, libudev, udisks, upower
- systemd's udev and libudev, udisks2, upower
(and udisks2 was actually forked to storaged and later unforked). Another
example is the handling of device ACLs for locally logged in users, which
has gone through:
- POSIX groups that users had to be manually and statically added to
- pam_console
- ConsoleKit with HAL integration
- ConsoleKit + udev-acl (corresponding to the DeviceKit move above)
- systemd-logind + udev-acl (corresponding to the systemd move above)
Each of these solutions was touted to be the great modern way that fixes
all the problems of the previous obsolete solution. But it was often only
a matter of months until the "great modern way" has become the next
"previous obsolete solution".
So, in short, newer is not always better, and sometimes, something is really
unsalvageable, and denying that fact will only make you lose users.
Kevin Kofler
4 years, 8 months
F26 Self Contained Change: Module Build Service
by Jan Kurik
= Proposed Self Contained Change: Module Build Service =
https://fedoraproject.org/wiki/Changes/ModuleBuildService
Change owner(s):
* Ralph Bean <rbean(a)redhat.com>
We will deploy an instance of the Module Build Service to production
in Fedora Infrastructure. Other teams will use this service to produce
some "modular" content for the Fedora 26 release.
== Detailed Description ==
We will deploy an instance of the Module Build Service (MBS) to
production in Fedora Infrastructure. Other teams will use this service
to produce some "modular" content for the Fedora 26 release.
In short, the MBS is a workflow orchestration service on top of koji.
When a user submits a request for a new module build:
* A new tag is created in koji for that module build.
* A module-build macros package is synthesized and built in the new buildroot.
* The buildroot is linked with other module tags that it has declared
dependencies on.
* RPMs to be included in the module are rebuilt from source in the new tag.
* Kojira generates a yum/dnf repo from the new tag.
The compose tooling (pungi) will then pick up this tag and possibly
include it in variants for the compose.
For the Fedora 26 timeframe, we will lock down the users who can
submit to the MBS to a small number of Modularity WG members. This is
not ideal, but the thought is that we want to limit the amount of spam
that the MBS will impose on the production koji instance - we don't
want to interfere with the general release of Fedora 26.
In the Fedora 27 timeframe, we will open it up to all packagers after
we're sure MBS is sophisticated enough to throttle itself
appropriately.
== Scope ==
* Proposal owners: We are responsible for the development, deployment,
and maintenance of the Module Build Service itself. We have a
prototype already functioning. At the time of writing, we still need
to harden it for production, and have it vetted for deployment by
Release Engineering and Fedora Infrastructure.
* Other developers: We don't think that other developers will have to
make changes in response to this effort. The Base Runtime team (a
sub-team of the Modularity Working Group) will be working to prepare
content to be built in the Module Build Service.
* Release engineering: In order to make use of the Module Build
Service, we will need changes to pungi to pull rpms for a variant from
the koji tags created by the Module Build Service, but that is a
separate Change proposal
[https://fedoraproject.org/wiki/Changes/ModularCompose]. The owners of
this proposal intend to do that work ourselves in consultation with
Release Engineering.
* List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines: Note that we do not think there are any
packaging guidelines that will need to be changed in the Fedora 26
timeline. We would like to change the branching structure in pkgdb and
dist-git in the Fedora 27 release cycle (with a separate Change
document). We furthermore will need to submit new Module Guidelines
that describe best practices and requirements for writing and
maintaining modulemd definitions - similar to how the Packaging
Guidelines describe best practices and requirements for writing and
maintaining .spec files. We would like to avoid writing those Module
Guidelines for the F26 cycle and instead limit the number of trusted
module maintainers to a small subset of the Modularity Working Group.
Once they have experience building the base modules, we'll use that
experience to inform the docs we write for F27, at which time we'll
open up the Module Build Service to the rest of the community.
* Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 7 months
Re: Package removal for FTBFS: Add automatic orphaning?
by Christopher
On Sat, Aug 10, 2019 at 7:33 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> On 11. 08. 19 0:34, Kevin Kofler wrote:
> > Miro Hrončok wrote:
> >> Obviously, we can prevent this by only orphaning packages with NEW bugz,
> >> but that doesn't really solve anything, because lot of the retired
> >> packages were actually ASSIGNED/POST/MODIFIED (for months).
> > Of course they were, to prevent you from retiring them even sooner.
>
> If the only reason to set the status to ASSIGNED/POST/MODIFIED is to prevent
> **me** from retiring the package, something is fundamentally broken.
>
> If somebody has a legitimate reason to have a FTBFS package not retired, they
> can ask for some kind of exception from Releng, not provide inaccurate information.
>
I was actually trying to work on some of mine... one of the FTBFS
(thrift) I had was actually because of an optional python2-only
component from upstream I was intending to disable once F31 was
released, if I couldn't recruit a python person to help me fix it
(because I don't know python). But, the entire package was retired
anyway.... it was *very* much unexpected for me, because I thought I'd
have some more time to patch it once F31 came out (the package in F30
is fine... and I don't care about rawhide... I care about the latest
version of Fedora that people are actually using).
Several other packages I had were Java packages that I was still
trying to figure out the state of their BuildRequires which were in
modules. The last I read on this list was "there may be some news
about that"... and then *bam* RETIRED... at least one I know for sure
was marked ASSIGNED. At least one of these I had fixed the FTBFS once,
but then it broke again, so I left the same issue open until I could
fix that one also... but it also was retired.
This FTBFS policy is *TOO* aggressive, and very unfriendly to casual
packagers, and at a time of significant disruption in Fedora due to
modularity. There should be some extra leniency for a few versions
while the dust from modularity settles, and it *definitely* should be
orphaned first if the maintainer isn't responding to FTBFS bugs.
There's so much disruption going on in Fedora right now... things are
moving too quickly for casual packagers, and it seems like a lot of it
is behind the scenes, motivated by internal interests of RedHat, and
*not* what is in the best interests of the community. It was *not* the
right time to forcibly retire hundreds of packages while these changes
are occurring. Many of these broken packages are probably because
casual maintainers like me are struggling to keep up with the changes.
Instead, now is the time to apply more mentoring, and leadership to
assist those packagers get things in order, to figure out how to get
those packages into appropriate modules, as needed, to assist in
patching for python3, to help them take orphaned BRs, etc.
This sends a very bad message, something along the lines of "only
hard-core, full-time, dedicated packagers allowed; you're on your own
and if you can't get things working in Fedora, you're out".
Also, I have a question about retirement as it pertains to modularity:
let's say a package was retired because its BRs moved into modules....
but now the only way to get the BRs (short of packaging all the java
stuff myself) is to put it in a module. Can I do this for a retired
package? Does ursine packages have to be un-retired in order to create
a module?
4 years, 10 months
