On Mon, Oct 21, 2019 at 03:36:53PM +0200, Fabio Valentini wrote: > 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. Exactly. (Though, I don't think it is wise to build something complicated from coprs — they are intended to allow the rules to be relaxed, but the obvious corollary is that there is less stability and reliability. The rules we have in the distro how packages must behave might be stiffling and annoying, but they are there for a reason...) > > 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. I consider our discussions to be technical and at a good level. Even this thread: there have a been a few flare-ups, but that's just a handful, and just people being tired and putting a few words in the wrong place rather than any personal attack. The problem is hard. If there was an obvious solution, we wouldn't be having this discussion. > > > > 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. I very much hope we can grow our packager base. Packaging in Fedora is definitely harder than it used to be. We still haven't really recovered from pkgdb retirement, various infra tools don't have enough support, etc. No easy solutions to this problem either, but I think keeping packaging simple (or at least not more complicated than it currently is). Zbyszek _______________________________________________ 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
