On Tue, 14 Jun 2022 19:20:22 +0100 Sérgio Basto <sergio@xxxxxxxxxx> wrote: > On Tue, 2022-06-14 at 07:05 -0700, stan via test wrote: > > There are a lot of dependency problems in rawhide after a large > > update > > a few days ago. I'm attaching the list in case anyone is interested > > in > > pursuing them at this early date. One, that seems to be with gdal- > > libs, > > is holding up a perl update, and there also seems to be a kde > > conflict. > > First you should report is on Rpmfusion mailing list , > I think Rpmfusion need rebuild his perl packages > I didn't think of that because all the gdal packages are fedora packages. Where does the rpmfusion link to the perl block come from? I see that you requested a mass rebuild of packages that depend on perl on the rpmfusion list. Do you still want me to do so? Normally, if I see things like this that don't resolve in a short time, I will open a bugzilla for the offending package. But, because there were so many this time, I didn't think that was feasible. And it is still early in the release cycle, with lots of changes and churn, so it is somewhat expected that there are going to be dependency problems. The only way that I can see to end such problems forever, is to have a relational database of every package with views of dependencies and what depends on them. Then the build system could refuse to build a newer package unless all the things that depend on it are included. Right now packagers take care of that manually and with dependencies in the spec files, a lot of work and prone to error as things change over time. If the relational database had every file of every package, then we could also avoid package naming conflicts in this way too. That would be a little larger database, but well within the capabilities of a database server like postgres. I think having such a database would also make updates very fast as the relational database could automatically use triggers to update all dependent databases atomically, removing the necessity from the package manager. So the database manager could just use queries of the database instead of figuring it out for itself. _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
