On Tue, 16 Feb 2010 15:21:19 -0600, Jonathan Nieder <[email protected]> wrote: > Hi James, > > James Westby wrote: > > > We have the Vcs-* fields in debian/control now that allow you to find > > the Vcs for the package you are looking at, and this is very useful. I > > think there is room to extend this a little further using automated > > tools to record information about which revision was built as well. > > I have an alternative idea: how about standardizing tag names to use > when uploading a package?
That would be a good idea to have in addition to this one. > People could get the information you want by looking at the > appropriate tag in the repository pointed to by Vcs-foo. Except that as I said, you don't know that the tag in Vcs-foo was what was actually used to build the source package you have. > It would not increase the size of the control file. More importantly > to me, it would not be yet another facility for users not using > *-buildpackage to learn about and get correct; it is already a pretty > common practice to tag uploaded revisions. Yes, and it is beneficial on its own to do that. I'm not sure whether those not using *-buildpackage would have to do it, it depends what tools were created. > The information about dirty trees would have to be put elsewhere, > though. Maybe a magic line in debian/README.source, or if necessary, > maybe this information would need to be in control (forgive me, I > don’t know what is necessary to make data accessible to the UDD). Editing the source to write a hash of the same source in to it? That's not ideal. I'm not sure if UDD can currently access the contents of the package. It would probably be less work for it to read from the .dsc either way. > Do you have example use cases for this data in mind? I think that > would be helpful for thinking about it without speculating too much. I do. We are working in Ubuntu to have packages built directly from bzr, and mirroring all packaging two ways between source packages and bzr. We are doing this so that you can use bzr on any package, while not having a flag day where everyone must switch, as source packages can still be used if there are any issues. The key to this is the bot that synchronises the two. Currently you can't build directly from bzr in to the archive. That means that if you use bzr you have to push, build and dput. This leaves a race condition where someone can push and someone else can dput something else. Therefore the bot has to detect whether the same thing was pushed as was uploaded. Building the source package can do allsorts, so we can't compare the built source to the VCS, and we don't want to build the source again, and even if we did it still wouldn't necessarily match (e.g. timestamps being written to generated files.) Therefore we use heuristics to work it out. This proposal would make that process easier and more reliable. If we know that the source package wasn't built from bzr then it will be a collision. If we know that they were built from different revisions then it probably differs. Therefore we want to know what revision id was built in to the source package we have. However, often people will repeatedly test build their uncommited changes, then when they are happy commit and upload the package that was already built. In order that we can not be fooled by this we would want the dirty flag. In order to notice that the revision that was pushed differs to what was built but has the same contents then we want the hash. Yes, it's not infallible, but we're not worried at this stage about people subverting the system by intentionally putting in misleading values or similar. I hope that makes my use-case clearer. Thanks, James -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
