[pkg-bacula-devel] Merging the 'development' branch: 01-3f141b4 -> 04-19ae64a (+ 11-123a8b6)

Luca Capello luca at pca.it
Wed May 9 09:57:54 UTC 2012


Hi Hauke!

On Mon, 07 May 2012 22:02:04 +0200, Jan Hauke Rahm wrote:
> On Wed, May 02, 2012 at 04:37:01PM +0200, Luca Capello wrote:
>> QUESTION: what is the rationale for using '@debian_hostname@' instead
>>           of relying on upstream '@basename@' or '@hostname@'?  We
>>           should diverge from upstream only if needed, and in this
>>           case I do not see any real advantage.
>
> I honestly don't remember. Thinking back, I assume that during later
> commits @basename@ broke something and, to have less patches touch the
> same lines over and over again, I made that change in an earlier commit.
> But I really don't remember, sorry.

No problem, I should have replied *way* before.

> That left aside, please note that I consider anything like this broken
> anyway. First replacing all @hostname@ with the building machine's
> hostname and later on replacing that particular hostname with a default
> for the config files is not only insane, it's also broken. My default
> build host's name is 'ca'. You can imagine how many lines were messed up
> when the scripts tried to replace 'ca' even within words.

Now I got the meaning of 'broken', I was erroneously thinking about the
fact that it does not build at all, sorry.  And I agree on all your
other statements.

> One reason why I stopped working was that the build system was so broken
> that I couldn't support any other upload with it. The work I did was to
> restructure all of it. Taking singular patches will make it better but
> it's still just crap as long as those hacks are even in it. There is no
> way to assume a stable build environment if we rely on stupid build
> hostnames.

Fully agree.

>> Hauke, please note that this is an example of why I do not like
>> Git-styled debian/changelog [2]: if instead you write there an entry
>> each time you modify a file in the debian/ folder, then you do not need
>> to explain what your Git commit does.  The fact that there is no
>> explanation in debian/changelog and in the Git commit itself either is a
>> pity whenever someone wants to understand what is going on.  Just to be
>> clear: I fully agree with the commit, it is just that I prefer
>> self-contained and self-explaining commits :-)
>
> I don't get how you figure my changelog entries would have been any
> better or more-explaining than my git commits. I'm sorry for crappy
> commit messages but I assure you, I would most definitely never have
> written better one-liners in yet another file. :)

Actually, the Git commits are fine, the problem is that a
debian/changelog generated by git-dch does not include any touched file
for each commit, which is what IMHO makes difficult to read the changes,
see for example:

  <http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=7;bug=612352>

> Having said that, I still think that changelog changes within the
> technical commits produce, before anything, just a branch-and-merge hell
> as *every* merge process will lead to conflicts in d/changelog.

That is true, but it is slightly true for any other commit, see:

  <mid:87sjmb194r.fsf at gismo.pca.it>
  <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/2011-October/000092.html>

> If I had
> written proper git commit messages (And I'm sorry if you feel I didn't),

As I wrote above, they are proper commit messages, at the point I almost
copied them into debian/changelog ;-)

> you could *at any point* in the commit history let git-dch produce a
> changelog entry and release *that point* while still not having to deal
> with conflicts in later commits. That's a feature of git. If you don't
> want it, you could've used subversion. :)

I like to use Git, but again IMHO the VCS for Debian is the Debian
package itself, not Git neither Subversion or Mercurial or
NAME_YOUR_FAVORITE_VCS_HERE.  Maybe it is just me that as a
non-programmer see things differently, but with git-dch debian/changelog
we are obliging people to look at the Git repository to simply know
which file changed, something you can not do offline.

>> b) missing changes for s/hostname/debian_hostname/
[...]
>> Again, this is more than the simple "Rework[ing] patching to use 3.0
>> (quilt)": you changed the final result and there is no documentation
>> about the rationale.  Never mind, I recorded the missing changes:
>
> As said above, the build system is more than broken. Relying on it is
> dangerous and wrong in my opinion. Whatever fix you apply to it, it'll
> never be good. I wanted to get rid of it and thus later didn't care
> anymore about these useless changes.

Got it ;-)

>> QUESTION: what is the rationale for unapply-patches in
>>           debian/source/local-options?
>
> When I put that in there, dpkg did not automatically unapply patches
> when applied right before building. Patches were thus applied in the git
> repo which was overly annoying. dpkg was changed. This commit is thus
> rendered obsolete.

Ah, yes, I completely missed that point!

> Thank you and all those who recently jumped in here for taking care of
> this. I'm truly sorry for having started enthusiastically and then just
> stoped. Much changed at work, not only related to our use of bacula, and
> I don't see how I can be of much help anymore. I'll stick around and try
> to read the mail on the list as you're in part discussing my old
> commits. I hope I can be of help with that at least -- even if I'm slow.

No problem for being slow and please do not be sorry: you *did* the work
and I *had not* promptly looked at it, so I am to be blamed as well :-)

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20120509/2c8a07d2/attachment.pgp>


More information about the pkg-bacula-devel mailing list