Re: [Gnu-arch-users] Re: tla file-locking (good idea or bad idea?)

[Jeremy Shaw]

At Wed, 21 Jan 2004 16:57:00 -0800,
Dustin Sallings wrote:
> 
> 
> On Jan 21, 2004, at 16:11, Jeremy Shaw wrote:
> 
> > (4) Have the autobuilder build on its own branch
> >
> > I am still exactly not clear on how this would work. I think maybe
> > there is a developers branch and an autobuilder branch. Before the
> > autobuilder builds, it tries to merge everything from the developers
> > branch, into its local branch. If there is a conflict, it dies and
> > sends an email?
> 
>       There shouldn't be a conflict unless the autobuilder is changing stuff 
> that other people are changing.

Yes, that's the whole point. Both the autobuilder and the a developer
can change the debian/changelog. Provided the developer does not do it
while the autobuilder is being the corresponding package there is no
problem. We used cvs file locks to enforce this in the past...
 
> > If a developer wants to update the debian/changelog, then they have to
> > merge the debian/changelog from the autobuilder branch into the
> > developer branch, then edit and commit (in the developers branch). Of
> > course, if they doing this while the autobuilder is building, they
> > won't know they caused a problem until the next time the autobuilder
> > tries to compile that package?
> 
>       It's not exactly clear to me how you use this changelog, but it sounds 
> like it's used for more than one thing and it sounds like that that 
> ends up being a process problem for you.
> 
>       On one hand, you want it to mark the successful completion of a build 
> by your autobuilder.  On another, it's the kind of thing users go in 
> and edit.  Is it possible to separate this into two files/concepts?

In the source, the topmost entry in the debian changelog determines
the version number of the binary package it generates. The
debian/changelog is also included in the binary package so you can
know what changed. As a result, it has to be updated before the
package can be built. (All debian packages must have unique version
numbers -- it is invalid to have two debian packages with the same
version number but different contents).

The autobuilder has to be able to update this version number itself,
because it often rebuilds packages automatically (based on build
dependency information encoded in the debian control files). So if I
update package A, the autobuilder will realized that package B also
needs to be rebuilt and will do it.

The developers need to edit the debian/changelog file is because there
are some situations where the changelog must be modified in a manner
that can not be done automatically by the autobuilder.

We aren't using the the debian/changelog to mark successful builds,
that is logged seperately in a database. We are however, trying to
avoid commiting a debian/changelog entry for a debian package that
never existed (because it failed to build).

The problem, really, is cordinating the update of the debian/changelog
so that man and machine aren't making incompatible modifications at
the same time.

Jeremy Shaw.

> > Also, its valid (though somewhat frowned upon) to build the package by
> > hand and upload it. I am certain people will forget to merge the
> > debian/changelog from the autobuilder branch to the developer branch
> > before building. That won't cause any problems, except lost time. But
> > lost time still sucks.
> 
>       This also seems like a process problem.  You described why you don't 
> want people building stuff by hand and uploading it, and are now using 
> it as a reason to avoid this solution.
> 
> -- 
> Dustin Sallings
>