Re: Modularity and the system-upgrade path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 21, 2019, 15:17 Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
> > If I were to start from scratch on this, I would look at the simplest
> > solution I would want from Boltron. I want to make it so a package team can
> > make a set of packages in a repository and work out how I can interact with
> > other repositories. I also want to easily build that package set in ways to
> > work on different versions of an operating system.
>
> The question is whether this team wants to do the "heavy lifting"
> (which might or might not actually be very heavy), of integrating with
> the rest of the distro. If they don't, then Copr is the answer: it
> provides all the answers, including automatic rebuilds.
>

The problem is that COPRs do not have any way of communicating with
each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I grab
from copr-B and it has libfoo-2.3.2-2 then I am going to replace
copr-A's packages which may break what I wanted from there. I am
saying that if we look at a way that they can clearly communicate
these problems to the user then we have fixed that.

Why not specify those requirements in RPM Requires? That's what they are for.


Also there needs to be a way to communicate that an upgrade from F32
to F33 will break a system because copr-B has no F-33 packages.

This already works somewhat, the only change that would be needed is setting skip_if_unavailable = false for COPR repos (I think they're set to true right now).


> If they do, and they invest in following the packaging guidelines and
> and the release cycles and whatever we say makes the package suitable
> for users and other packagers to build on, they get to put the package
> in the distro.
>

>From what I have heard over and over is that it isn't the packaging
guidelines which are a problem.. it is dealing with threads like this
or the continual drama churn we have. Investing in the OS means a lot
of emotional energy which a lot of people have no room for in our
current world. In some ways I see being able to bolt things into Coprs
as an escape from dealing with constant absolutes of 'your wrong!'
which most of our messages devolve to.

The problem is that our current 20,000 packages is a LOT and most
software needs more than we actually have packaged. That means
continual growth, but our other needs of 'I need this as quickly as
possible', 'I expect you to have fixed all these things', etc are more
than most volunteers can deal with at this size. We end up shutting
down and yelling at each other because deep down we just want the
noise to stop.

Yes, I agree, the current growth of the package set isn't sustainable if we don't also scale up the contributor base. I suspect that there are a few handfuls of packagers who maintain hundreds of packages, while the majority only maintains only a handful of packages. And relying on the "overcommitters" (pun intended) to keep the distro running isn't working so well.

Fabio





--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux