On Mon, 21 Oct 2019 at 09:37, Fabio Valentini <decathorpe@xxxxxxxxx> 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. > Because this isn't about a package but a set of packages. I may not know that you are going to use Repo-B.. but may have known about Repo-C which did work. [Maybe it turns out that libfoo-2.3.2-2 in repo C does work because it had a patch.] The problem I am seeing is that with N thousand copr packages, you can only express some amount of stuff in the packages themselves. In the end there are parts which need to be expressed more abstractly higher up. [I know I work with copr-X, I don't work with copr-Y.] etc. This is a common problem which shows up because people have problems they want to solve, they google to find a solution and htey cobble together something from 10 different repositories which may or may not have been designed to work together. [This will also happen in container combinations etc so if we can help fix it here.. it can be used elsewhere.] The answers of 'well dont' do that', 'get them to put them in the OS', etc etc have not worked for 20 years. The idea of adding more packagers to the community hasn't worked either.. even before pkgdb was retired.. there was no 'growth'.. there was a set number of people who were active (they may not be the same as now.. but the number was the same). I would say 350 active packagers is our Dunbar number but that is getting far into the pseudo-science weeds. Is that the number of packagers? No.. there are a lot of people who will do a small set and have no interested outside of that. Giving them the tools which can allow them to communicate what their repo can and can not do seems like a good thing. -- 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
