The xfsprogs debian package

The xfsprogs debian package

[Christoph Hellwig]

[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?
> 
> Also Nathan & Anibal - if there is no consesus for keeping the old
> scheme what about dropping it?  We can still keep the main Debian
> packaging in the tree, and find a way to generate a normally NULL
> Debian diff for it.  I'm not quite sure how to do it, but there
> must be some way.
---end quoted text---

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: The xfsprogs debian package

[Aurelien Jarno]

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?

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.
  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.
  It's great if xfsprogs can be translated in other language, but the
  priority is given first to Debian specific packages.
- 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.
- 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.

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.

Aurelien

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: The xfsprogs debian package

[Nathan Scott]

[-- Attachment #1.1: Type: text/plain, Size: 4166 bytes --]

Hi there,

On 20 September 2011 20:58, Aurelien Jarno <aurel32@debian.org> 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

[-- Attachment #1.2: Type: text/html, Size: 6017 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: The xfsprogs debian package

[Aníbal Monsalve Salazar]

[-- Attachment #1.1: Type: text/plain, Size: 577 bytes --]

On Wed, Sep 21, 2011 at 08:48:19AM +1000, Nathan Scott wrote:
>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.

I'll manage it without changing its current Debian ownership. I'll keep
the list as the Debian package owner and Nathan and myself as uploaders
to the Debian package.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs