On Sat, Mar 2, 2024, 09:06 Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

>
> On Friday, March 1st, 2024 at 20:27, Jason Tibbitts <j...@tib.bs> wrote:
>
> >
> >
> > >>>>> Adam Williamson adamw...@fedoraproject.org writes:
> >
> > > Honestly, we could really use more automation here, but it's a fairly
> > > hard thing to do reliably and there just isn't anybody specifically
> > > tasked with it so it doesn't happen.
> >
> >
> > So sure, we could use something but it doesn't have to start out as some
> > complex fully automatic system. (Would be nice, but...)
> >
> > Can we agree that we'd be at least half of the way there if we just had
> > a well defined way to:
> >
> > * Know what package depend on the one you're updating
> >
> > * Easily bump and chain-build all of that in a side tag
> >
> > Surely there's a reopquery or fedrq command line that will find at least
> > most of what needs to be rebuilt. It doesn't have to be absolutely
> > perfect but it can't be that hard to get close. I know there's a
> > distinction between build and runtime dependencies and rich/conditional
> > dependencies complicate things a bit, but those much smarter than I am
> > must have already figured out how to get something that's at least
> > somewhat useful.
> >
> > Once you have the package list, maybe it needs some kind of sorting
> > before you can just bump and chain-build things, but I think in many
> > cases it doesn't. So, yes, a 100% tool would be really hard but the 80%
> > tool really shouldn't be that bad, and almost any tool would really help
> > people out.
> >
>
> My idea was to write a Python script based on libdnf APIs and third party
> python modules to create a dependency tree of packages, so that also Mass
> Rebuilds can be run by the tree levels instead of alphabetically. However,
> I had no time to further develop the idea, as I also learn how to fetch
> data from libdnf (and if that is possible at all).
>

The problem with this idea is that the dependency tree is not a "tree", but
a graph that is *not* acyclic. So you just *cannot* make a linearized
version / topographic sort without some amount of "bootstrap" changes to
break (or ignore) some of the involved dependencies.

Fabio


> Mattia
> --
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to