On Thu, Apr 16, 2020 at 01:57:40AM +0200, clime wrote: > On Thu, 16 Apr 2020 at 00:52, Dan Čermák <dan.cermak@xxxxxxxxxxxxxxxxxxx> wrote: > > > > clime <clime@xxxxxxxxxxxxxxxxx> writes: > > > > > On Mon, 13 Apr 2020 at 10:55, Dan Čermák <dan.cermak@xxxxxxxxxxxxxxxxxxx> wrote: > > >> > > >> Hi list, > > >> > > >> my question is pretty much $subject: Why doesn't Koschei kick of > > >> real builds off packages on dependency changes? From my naive POV that > > >> looks like the missing piece to give us the "OBS-experience". Having > > >> that at least in Rawhide sounds like a good thing to me. > > > > > > Dan, can I have some basic questions to this because I don't know OBS. > > > > > > Could you describe the feature in more detail with regards to > > > auto-rebuilding and when it is useful? > > > > In a nutshell: OBS will in its default mode rebuild each package once > > one of its direct or indirect dependencies changes. > > > > That is pretty useful, because as a maintainer you can just update a > > library and you don't have to do a thing to get dependent packages > > rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" and > > "need a provenpackager to rebuild dependent packages of ABC" emails on > > devel. Also, if a package fails to build due to an update, it will be > > noticed right away and not until the next mass rebuild. > > > > Additionally updating a bunch of packages will no longer require that > > you figure out the build order yourself: the build system figures it out > > itself by rebuilding your packages until the transitive dependencies > > stop changing. > > > > All of this is of course only really viable for Rawhide and already > > released Fedora branches should not be run like this, because one wrong > > update could wreck the whole distro. > > Thanks, that was a nice explanation. I personally believe there is a > good solution in extending koji and rpm. > > koji to be able to rebuild the same source package again and again > while passing a different increasing number to rpmbuild through > --define and rpm to put that number into rpm name if it was specified > to the following position: > > python3-colcon-ros-bundle-0.0.14-1.fc31.<buildid>.noarch.rpm > > It can be just a short build id specific for the given package (i.e. > how many builds there were for the given package). There might be a > little bit of trouble to keep <buildid> meaningfully increasing in > case of multiple parallel builds but I think it should be possible. > > An advantage over the rpmautospec approach is that this will just work > for all the packages out of the box, i.e. no matter what macros they > are using. Including the build number in the release field was part of the ideas submitted for feedback when we started looking at the auto-release question and there seemed to be a consensus about not wanting to have the release depend on the build system. rpmautospec allows to rebuild a commit multiple times and you will get a different release everytime, that release is computed using the information from the build history of the package, made available via git tags, so the build system is not involved in the computing of the release field (which thus can be reproduced locally). Pierre _______________________________________________ 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
