Re: Recording VCS information in the source package info
On Tue, 16 Feb 2010 15:21:19 -0600, Jonathan Nieder <jrnieder@gmail.com> 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
Reply to: