Re: disabling yum modular repos by default?
by Zbigniew Jędrzejewski-Szmek
On Wed, May 10, 2023 at 07:09:49PM +0200, Peter Boy wrote:
> I suppose I would belong to the latter. From a Server admin’s POV the modules are a great chance to keep some backwards compatibility with our fast pacing distro. The most prominent example is PostgreSQL. It is not so rare that the new major version requires an adjustment in the application programme or at least an extensive test. And every major update also requires a migration of the entire data stock. Modularisation is a welcome opportunity to quickly switch to a new release and use new capabilities, but to carry out the adaptation / tests with PostgreSQL at your leisure.
There's a proposal to provide parallel postgresql versions via plain
old normal traditional boring packages:
https://src.fedoraproject.org/rpms/postgresql/pull-request/59
Zbyszek
1 year, 1 month
Re: Modules without modularity
by Kevin Kofler
Petr Pisar wrote:
> I understand the horror that you can have two packages which cannot be
> installed at the same time. The same as you cannot start httpd and nginx
> services at the same time. But now the conflict is visible on RPM level.
You can actually, if you set them to different ports.
But the issue here is that you can have 2 completely unrelated packages
clashing over the version of some transitive dependency. Imagine not being
able to install a KDE application on GNOME or vice-versa because of the KDE
and GNOME stacks requiring a conflicting version of some "plumbing-layer"
library. That is exactly the kind of scenario I and others want to avoid.
> Of course. My proposal does not forbids it. If users of the
> parallel-installable packages are fine with rewriting all their RPM
> dependcies and file locations in their applications, then
> parallel-installable packages are a perfect solution. It's simply a
> different problem with a different solution.
It is a different solution indeed, but I disagree about it solving a
different problem. It solves the *same* problem in a different, better (from
the end user's perspective – I know it is more work for the packager) way.
Kevin Kofler
1 year
Re: Modules without modularity
by Petr Pisar
V Tue, Jun 20, 2023 at 03:47:13PM +0000, Mattia Verga via devel napsal(a):
> Il 20/06/23 17:31, Zbigniew Jędrzejewski-Szmek ha scritto:
> >
> > [1] https://src.fedoraproject.org/rpms/postgresql/pull-request/59
> >
> > Zbyszek
>
> Isn't the package name required to match the name of specfile?
>
It is.
But you can work around it by keeping the main package nonexisten (i.e.
moving all files from "%files" section to "%files -n MY_FUNNY_NAME" section and
removing "%files" section). Source package would retain main package name,
but there wouldn't be any binary package of that name.
But I'm not sure whether relengs won't protest that they have multiple
source packages with the same name in a sources repository.
-- Petr
12 months
Re: Modules without MBS
by Remi Collet
Le 13/06/2023 à 18:32, Petr Pisar a écrit :
> Hello,
>
> as it seems that module build infrastructure isn't getting any better, as
> modular YUM repositories are going to be deconfigured
> <https://fedoraproject.org/wiki/Changes/No_default_fedora-repos-modular>,
> there is a time to look at different ways how to package alternative content.
Another way/proposal
Keep "modularity", but drop MBS
1/ create a stream package which defines few needed stuff
mostly
- %dist => .module+name+stream.distro
- %modularitylabel
and possibly the .yaml template
2/ modify createrepo
so all the packages with modularitylabel=name:stream:*
are be part of name:stream module
Done.
And we have something which works and have been heavily tested
Yes this is a 1 level only modularity.
P.S. §1 is what MBS does somehow magically
and packager know what to build, in which order,
something that MBS also try to magically compute
12 months
Fedora CoreOS Meeting Minutes 2023-06-28
by Dusty Mabe
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2023-06-28/fedora_core...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2023-06-28/fedora_core...
Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2023-06-28/fedora_core...
========================================
#fedora-meeting-1: fedora_coreos_meeting
========================================
Meeting started by dustymabe at 16:29:14 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-06-28/fedora_core...
.
Meeting summary
---------------
* roll call (dustymabe, 16:29:19)
* Action items from last meeting (dustymabe, 16:33:28)
* there were no action items from last meeting (dustymabe, 16:33:35)
* please review
https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault
and provide feedback for travier and ravanelli (dustymabe,
16:36:00)
* F39 Change: No default fedora-repos-modular [Consideration]
(dustymabe, 16:37:26)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1513
(dustymabe, 16:37:43)
* AGREED: We will communicate the removal of modular repos from Fedora
CoreOS in F39 and give users steps to resolve the problems on the
systems. If users are running `next` or `testing` streams they will
also notice updates not coming in before there `stable` systems stop
receiving updates. (dustymabe, 16:56:56)
* Adding an LVM devices file by default (dustymabe, 16:57:17)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1517
(dustymabe, 16:57:21)
* LINK: https://github.com/coreos/ignition/issues/739 (travier,
17:10:20)
* AGREED: we will ship an empty lvmdevices file for new installs and
also add a migration script for existing systems that will populate
an lvmdevices file with appropriate content so that existing systems
using LVM will continue to work. (dustymabe, 17:19:23)
* tracker: Fedora 39 changes considerations (dustymabe, 17:19:59)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1491
(dustymabe, 17:20:04)
* open floor (dustymabe, 17:31:14)
Meeting ended at 17:38:38 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dustymabe (126)
* travier (43)
* zodbot (18)
* spresti (16)
* ravanelli (12)
* quentin9696[m] (9)
* jdoss (4)
* apiaseck (4)
* gshomo (2)
* marmijo[m] (2)
* Guidon (2)
* mnguyen_ (2)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
11 months, 3 weeks
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
by Chris Adams
Once upon a time, Miro Hrončok <mhroncok(a)redhat.com> said:
> On 04. 08. 23 14:45, Chris Adams wrote:
> >Could the repo config be removed by having fedora-repos Obsolete:
> >fedora-repos-moduler <= 39?
>
> That has already been done. But when the upgrade happens, the repo
> config is still there, to be removed in the transaction that fails.
Ah, that makes sense, sorry. :)
--
Chris Adams <linux(a)cmadams.net>
10 months, 2 weeks
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
by Adam Williamson
On Fri, 2023-08-04 at 11:13 -0400, Stephen Smoogen wrote:
> 2. We need to work out 1-2 methods we 'support' for upgrading which of the
> ones below I would say D and A where certain tooling will check to see if
> the upgrade is possible and then alert if it isn't and try a method of
> turning things off if ok.
Well, this is, effectively, exactly already the case. We already have
specific supported methods of upgrading:
https://docs.fedoraproject.org/en-US/quick-docs/upgrading/ (basically,
graphical upgrade for Workstation; dnf system-upgrade for everything
else; both using the default stock repository configuration). The
tooling that checks to see if the upgrade is possible and alert if it
isn't is...well...the upgrade process. It does that.
The issue as described affected the "supported" methods of upgrading,
except that (as described in the correction) it doesn't actually cause
immediate issues in real-world cases because of the 'stale' tree that
remains on the official repo location.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
10 months, 2 weeks
