[Debian-med-packaging] git clean and debian/rules clean (was: samtools i386-buildable)

[Afif Elghraoui]

On الأربعاء 16 أيلول 2015 06:02, Andreas Tille wrote:
>>> IMHO using Git should be no excuse to break good packaging practice to
>>> > > be able building packages twice in a row.
>> > 
>> > I would say the reverse: Git provides us great tools to reset a working
>> > directory, and it is a waste to not use them.

I actually agree with both of you. I think one way to have a compromise
here would be to keep the output of git ls-files in a file somewhere in
the package. The clean target can then just remove everything that is
not listed in that file. How does that sound?


>> >   10 years ago, it could have been
>> > reasonable to say things like "I am a darcs|bzr|mercurial|whatever user, Git
>> > has no future, I will not spend my time learning it", but as of today anybody
>> > who want to do serious Debian development needs to know Git.
>> > 
>> > Our packages are writable for all Debian developers; in return I think that we
>> > should be a bit more firm about asking people to make their changes in the Git
>> > repositories, and avoid working in the raw source packages, which are merely a
>> > vehicule to send the source to the autobuilders.  
> I beg to differ here (not about the role of Git since there is no doubt
> about its role).  There are people who working on QA tools and amongst
> these are people who check whether a package builds twice in a row.  And
> a clean target is a clean target and we should strive to get this
> working properly.  I admit I do not always reach this goal in all
> packages I touched myself.  .

This is where it's helpful to have a tool that can flawlessly do the
operation without having to spend time figuring out which files must be
removed.

> However, there is a valid point in the
> request to build twice in a row and it is wrong to force a certain tool
> upon somebody (how nifty and wide spread it might be).

I don't know about this-- when there are several tools or workflows that
are designed to do exactly the same thing, I think it's helpful to
standardize. For example, I try to avoid dealing with the packages in
SVN because I don't think it's worth my time to improve my skills with
svn or learn how to use svn-buildpackage. It seems some people here
prefer working in svn, but if I wanted to do something like what I just
did with samtools--- make some changes to a package that I"m not the
primary maintainer of -- I'd have been far less likely to have done it
were it in svn or bzr or something else.

I don't say this even because of my personal preference. I think our
current team policy of using quilt in git doesn't make much sense, but I
stick to it because it's the team policy and I don't have a proposal for
improving it.

In the end, the choice of workflow/tool affects the entire group--
leaving it up to each individual's personal preference can work against
the interest of the group.

regards
Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name