Hi there,<br><br><div class="gmail_quote">On 20 September 2011 20:58, Aurelien Jarno <span dir="ltr"><<a href="mailto:aurel32@debian.org">aurel32@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Sep 19, 2011 at 01:10:47PM -0400, Christoph Hellwig wrote:<br>
> [and now with the correct Cc list]<br>
><br>
> On Mon, Sep 19, 2011 at 01:09:36PM -0400, Christoph Hellwig wrote:<br>
> > Hi Aurelien, Nathan & Anibal,<br>
> ><br>
> > is there any chance we can get to a defintive agreement on how to<br>
> > maintain the xfsprogs package? So far the idea of releasing the<br>
> > upstream releases as Debian packages at the same time has worked<br>
> > great for both Debian, and us xfs developers (which to a large<br>
> > extents are heavy Debian users), but "inner" Debian circles heave<br>
> > always complained about it.<br>
> ><br>
> > Can we please get an explanation of why it is so in proper written<br>
> > englush, instead of doing by forced nmus?<br>
<br></div></blockquote><div><br></div><div>The forced NMUs are independent ... that's more a lack of time on my</div><div>part to keep up with current XFS development, so noone is doing the</div><div>uploads (and those doing NMUs don't talk to the xfs list, so their changes</div>
<div>tend to get lost). Its a bit of a mess, and largely thanks to me I guess.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
</div>First of all I have to point here that there is no issue in having the<br>
debian/ directory present in upstream, as long as the people doing the<br>
development upstream and in debian are usually the same (this condition<br>
is actually not true anymore with the latest dpkg format, which can<br>
ignore an existing debian/ directory, but that's not the point here).<br>
<br>
The problem is on the point of having a native package, that is not<br>
having a .diff.gz or a debian.tar.gz. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Not doing so causes a few issues:<br>
- Native packages are supposed to be Debian specific, not doing means<br>
they are wrongly identified by various scripts running in the archive.<br></blockquote><div><br></div><div>FWIW, the example below is the only example I'm aware of (AFAIK,</div><div>there are no other scripts ... *shrug* ... could be wrong there though,</div>
<div>but you'd think there'd be a big long list given the complaints).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
For example the translation of the Debian native packages done by<br>
Debian. In this case it means that Debian translators receive a mail<br>
each time a string is changed in xfsprogs in order to translate it.<br></blockquote><div><br></div><div>Yeah, this is annoying but I could never convince myself it outweighed</div><div>the huge advantages of having developers able to build packages from</div>
<div>directly within the source tree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It's great if xfsprogs can be translated in other language, but the<br>
priority is given first to Debian specific packages.<br></blockquote><div><br></div><div>The strings so rarely change in xfsprogs, that in practice this is not a</div><div>real issue (IMO) ... its more just a reason thrown up to give a reason,</div>
<div>for people who just have to have an opinion (of which there are many).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- Making xfsprogs a native package also means that the upstream version<br>
needs to match the version in Debian. If there is a need to do a<br>
change in xfsprogs directly in Debian like for the recent NMU, we end<br>
up with a version in Debian that has never existed upstream.<br></blockquote><div><br></div><div>That logic seems a bit flawed to me - there's never a reason to change</div><div>something "directly in Debian", that couldn't have been merged in the</div>
<div>development xfsprogs tree - and a coordinated, reviewed release done.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- For archive space reason, if one upload only needs a small change in<br>
the debian/ directory, it means a full .tar.gz has to be uploaded<br>
instead of a small .diff.gz or debian.tar.gz.<br></blockquote><div><br></div><div>xfsprogs is few 100KB in size, and is only uploaded once every few</div><div>months at most ... so again, not a hugely compelling argument when</div>
<div>you think about it (compared to the advantages, I mean, I don't doubt</div><div>some space would indeed be saved). </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Again I don't ask for not putting the debian/ directory, it's totally<br>
possible to have a non-native package with an empty .diff.gz or<br>
.debian.tar.gz.<br></blockquote><div><br></div><div>Having said all that, I really don't have a strong opinion - what xfsprogs</div><div>really needs is someone with the time to take ownership, and I've not</div>
<div>found the time recently. If someone would own it well, and for them its</div><div>easier to not have a native package (which it likely will be)... please go</div><div>ahead and manage the package however best suits.</div>
<div><br></div><div>cheers.</div><div><br></div><div>--</div><div>Nathan</div></div>