On Thu, Apr 16, 2020 at 03:07:37PM +0200, clime wrote: > 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." Thank you for finding that. The README was definitely out-dated, and it has been fixed. > and lines like this: > https://pagure.io/Fedora-Infra/rpmautospec/blob/3c208f17329940977cbe1552f3d1bbee35014f93/f/rpmautospec/tag_package.py#_53 > are not needed? This is not involved in the computation of the next release value. So, do we use the build history of the package to predict the next release value? Yes. Do we pull this information from the build system? No, we push this information from the build system into dist-git giving dist-git enough information to be self-sufficient. Could the build system not push that information? Yes, we're currently flagging commits in dist-git upon successful build. We could use another tool to add the tags then instead of doing it from koji but it would introduce more delays. But could we not use the build history of the package? Not with the approach we chose. Now, using the number of commit made since the last version bump would be one way to generate the release value which would be entirely contained within dist-git, but it isn't without drawbacks (the upgrade path can very easily be broken with this approach, it also does not allow to rebuild a package without doing a new commit to its git repo). We have considered those and chose not to pursue that idea. Adding a build number in the release field, would require even more involvement of the build system than our approach and would break the "contained within dist-git" idea. There are really multiple ways to solve these questions, we looked at a number of them including yours and made a choice that does not align with your idea, but the approach and POC we're proposing does fit the set of requirements, the UX we wanted to have and is working. I am not saying your approach could not work either. We just picked two different approaches, both of which are potentially valid. 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
