On Thu, 16 Apr 2020 at 14:12, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > On Thu, Apr 16, 2020 at 12:16:16PM +0200, clime wrote: > > On Thu, 16 Apr 2020 at 09:51, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > > > > > 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. > > > > Pierre, maybe we can start understanding each other here. > > > > > > > > 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. > > > > I have a different understanding here :). What you did in rpmautospec > > means that release _is_ dependant on build system because it is > > dependant on information owned by it. > > No, the code generating the release field does not rely on any information > provided by the build system, making it works fine locally. Erm, how do you generate the tags? Can you drop the build system relation? You are not making sense at the moment. If your plan is eventually to push those build git tags back to pagure so that people get some kind of temporary reproducibility (i.e. it will work only when no build is running), then that's a duplication of data, i.e. it is still not "dist-git is a single source of truth". You are duplicating what's in koji into dist-git needlessly. And it is _still_dependant on build system. Can you, please, read what I am writing and really think about it? With rpmautospec you are breaking so many software-design and programming common-sense rules that it is hard to even count. Why can't we join forces on a solution that makes sense and that will actually work? clime > > > 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 _______________________________________________ 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
