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. Yet another try: Are you saying this is not true? ... >From https://pagure.io/Fedora-Infra/rpmautospec/tree/master: "- Attempt to automatically calculate release numbers and generate an RPM changelog from the dist-git repository of a package and the information available in the Koji build system." and lines like this: https://pagure.io/Fedora-Infra/rpmautospec/blob/3c208f17329940977cbe1552f3d1bbee35014f93/f/rpmautospec/tag_package.py#_53 are not needed? >From what I see, you clearly _are_ using build system to generate release information. The fact that you are doing it through some tagging middle step is completely irrelevant cause it is just a middle step. > > > 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
