Re: The xfsprogs debian package

[Nathan Scott <nathans@xxxxxxxxxx>]

Hi there,

On 20 September 2011 20:58, Aurelien Jarno <aurel32@xxxxxxxxxx> wrote:

On Mon, Sep 19, 2011 at 01:10:47PM -0400, Christoph Hellwig wrote:
> [and now with the correct Cc list]
>
> On Mon, Sep 19, 2011 at 01:09:36PM -0400, Christoph Hellwig wrote:
> > Hi Aurelien, Nathan & Anibal,
> >
> > is there any chance we can get to a defintive agreement on how to
> > maintain the xfsprogs package?  So far the idea of releasing the
> > upstream releases as Debian packages at the same time has worked
> > great for both Debian, and us xfs developers (which to a large
> > extents are heavy Debian users), but "inner" Debian circles heave
> > always complained about it.
> >
> > Can we please get an explanation of why it is so in proper written
> > englush, instead of doing by forced nmus?

The forced NMUs are independent ... that's more a lack of time on my

part to keep up with current XFS development, so noone is doing the

uploads (and those doing NMUs don't talk to the xfs list, so their changes

tend to get lost).  Its a bit of a mess, and largely thanks to me I guess.

 

First of all I have to point here that there is no issue in having the
debian/ directory present in upstream, as long as the people doing the
development upstream and in debian are usually the same (this condition
is actually not true anymore with the latest dpkg format, which can
ignore an existing debian/ directory, but that's not the point here).

The problem is on the point of having a native package, that is not
having a .diff.gz or a debian.tar.gz. 

Not doing so causes a few issues:
- Native packages are supposed to be Debian specific, not doing means
 they are wrongly identified by various scripts running in the archive.

FWIW, the example below is the only example I'm aware of (AFAIK,

there are no other scripts ... *shrug* ... could be wrong there though,

but you'd think there'd be a big long list given the complaints).

 

 For example the translation of the Debian native packages done by
 Debian. In this case it means that Debian translators receive a mail
 each time a string is changed in xfsprogs in order to translate it.

Yeah, this is annoying but I could never convince myself it outweighed

the huge advantages of having developers able to build packages from

directly within the source tree.

 

 It's great if xfsprogs can be translated in other language, but the
 priority is given first to Debian specific packages.

The strings so rarely change in xfsprogs, that in practice this is not a

real issue (IMO) ... its more just a reason thrown up to give a reason,

for people who just have to have an opinion (of which there are many).

 

- Making xfsprogs a native package also means that the upstream version
 needs to match the version in Debian. If there is a need to do a
 change in xfsprogs directly in Debian like for the recent NMU, we end
 up with a version in Debian that has never existed upstream.

That logic seems a bit flawed to me - there's never a reason to change

something "directly in Debian", that couldn't have been merged in the

development xfsprogs tree - and a coordinated, reviewed release done.

 

- For archive space reason, if one upload only needs a small change in
 the debian/ directory, it means a full .tar.gz has to be uploaded
 instead of a small .diff.gz or debian.tar.gz.

xfsprogs is few 100KB in size, and is only uploaded once every few

months at most ... so again, not a hugely compelling argument when

you think about it (compared to the advantages, I mean, I don't doubt

some space would indeed be saved). 

Again I don't ask for not putting the debian/ directory, it's totally
possible to have a non-native package with an empty .diff.gz or
.debian.tar.gz.

Having said all that, I really don't have a strong opinion - what xfsprogs

really needs is someone with the time to take ownership, and I've not

found the time recently.  If someone would own it well, and for them its

easier to not have a native package (which it likely will be)... please go

ahead and manage the package however best suits.

cheers.

--

Nathan