Re: let missing-debian-source-format lintian tag be a warning!

2014-08-14 Thread Guillem Jover
On Wed, 2014-07-16 at 09:20:51 +0200, Raphael Hertzog wrote:
 On Wed, 16 Jul 2014, Guillem Jover wrote:
  The only reason for that warning right now is to pester people into
  either switching, which they should be doing out of their own
  volition anyway because people think the new formats are really
  superior and help them. Or so that people set it explicitly to 1.0
  just to shut up the warning, and then we have some kind of stats of
  how many people have been pestered… Which I think is the wrong way
  about trying to get people to switch.
 
 You see it only from a negative side, sure there are a few people who
 consider this message as pestering them but it really filled the role
 of the missing lintian warning for all people who create source packages
 from scratch and/or who take over old packages and use the lintian output
 as their todo list.

I'll take a long tail of packages that have not switched to new stuff
because they are practically unmaintained or because the maintainer
didn't yet find the time to switch, than one that is composed of those
plus ones from disgruntled or alienated maintainers, any day.

Removal of that warning is just a step in trying to heal those “wounds”.

 Certainly that without this message the adoption rate of the new formats
 would not have been so good as it has been (which despite some of the
 critics, is probably one the best adoption rate for such wide scale opt-in
 changes in the Debian history).

I don't think the adoption rate has been much different in relative
terms to any other such change in Debian, and I expect the long tail
to linger for a long time. I also think a bigger factor was the very
aggressive campaign at the beginning, which at the same time seemed
counterproductive as it pushed the wrong buttons for quite some people.

 So to sum it up, I'm OK for dropping that message but only if lintian gets
 the corresponding tag raised to a warning level and IMO it still makes
 sense in the long term for dpkg-source to abort if debian/source/format is
 missing, precisely because the historical default no longer matches
 Debian's desired default.

It does not make sense, because when it comes to source packages, there
isn't and never has been a default from dpkg-source or even Debian.
dpkg-source builds whatever is provided by the maintainer, and it does
not (and cannot as currently designed) perform any format conversion on
its own (compared to dpkg-deb f.ex.).

There might be a project preferred or recommended format, or packages
such as dh-make or debmake might have such default but certainly not
in dpkg-source or Debian.

Bumping that lintian tag to a warning would be rather inappropriate IMO.

Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140814082956.ga13...@gaara.hadrons.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-21 Thread Charles Plessy
Le Wed, Jul 16, 2014 at 01:35:04AM +0100, Colin Watson a écrit :
 
 Having followed it up after last year's DebConf, I've been absolutely
 sold on git-dpm, FWIW; I find it does a great job of making the patch
 queue pleasant to maintain in a git-native style while providing a nice
 easy-to-read export to 3.0 (quilt) - that is, you don't actually use
 quilt manually.  At that point 3.0 (quilt) makes a lot of sense to me as
 an automatable serialisation of upstream + patch queue + packaging with
 a minimum of package-specific code, and the only way in which it imposes
 a patch system is that the tools I'm using need to export to it (which
 is really not that much more than git format-patch with some care about
 file names, so no big deal, and people can still inspect and modify my
 source packages without my fancy tools).
… 
 gbp-pq is of course fairly similar.  I looked at both although I admit
 that I only experimented extensively with git-dpm.  They both look like
 they should get the job done, but git-dpm just seemed more featureful
 and polished to me based on its documentation, and I really like the way
 it handles the results of rebasing the patch queue.

Thanks a lot Colin for your inspiring answer.  After reading it, I tested both
tools and I chose gbp-pq because my packaging team is already using
git-buildpackage a lot (and because git-dpm quilckly gave me an error).

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140721135141.gb25...@falafel.plessy.net



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-18 Thread Colin Watson
On Fri, Jul 18, 2014 at 10:17:28AM +0800, Thomas Goirand wrote:
 Got it now. And I agree. It'd be awesome if we had something like:
 quilt git-cherry-pick git-ref
 
 which would do the work. Then it wouldn't be a problem.

  git-dpm checkout-patched
  git cherry-pick COMMIT
  git commit --amend
  # add patch headers
  git-dpm dch -- 'description of change'

:-)

 Also, it'd be super nice if someone gave a talk about git-dpm at
 Debconf, to explain to everyone how it works. Anyone?

There was one last year - I don't have time to hunt out the video right
now but it should be quite easy to find given that.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140718225825.gb9...@riva.ucam.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-17 Thread Thorsten Glaser
Guillem Jover wrote:

Exactly. I don't have any intention to change the current dpkg-source
default behavior in that regard.

ACK.

But people who touch packages without d/s/format can just
write 1.0\n into it, to retain existing behaviour without
the warning. Still, changing the default is bad…

 like /etc/dpkg/dpkg-source.cfg, which admittedly doesn't exist yet.

But sure, that (and its $HOME counterpart) is a good idea and is
something I'll be adding (possibly for 1.17.12) when also adding

This has the potential of breaking all sorts of build scripts
and dpkg wrappers that assume default behaviour when an option
is not specified. This would also require all options to have
no- counterparts to disable them again. (This is nicely solved
in BSD land (including mksh getopts builtin) by the way, where
there are no --gnu-long-options: -x turns -x on, +x turns -x off.)

All maintainers of software that has historically had default
behaviour and no configuration files, and is switching to use
configuration files, either user-specific ones (can break the
scripts) or system-wide ones (can break scripts as well as
users) should, in the same go, add an *environment variable*
to disable these. (An environment variable will just be ignored
by older versions of such software; a --no-config-file option
will usually error out on older versions and is thus a really
bad idea.)

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lq8fhg$pec$1...@ger.gmane.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-17 Thread Thomas Goirand
On 07/17/2014 02:29 AM, Tollef Fog Heen wrote:
 ]] Thomas Goirand 
 
 On 07/15/2014 09:42 AM, Charles Plessy wrote:
 I am not a big fan of the 3.0 (quilt) format because it imposes a patch 
 system.
 In particular, this format does not make much sense when managing the source
 package with Git.

 I'm not sure I'm following you. I do use git for packaging, and I have
 no problem at all with format 3.0 (quilt). I was resisting to progress
 and reluctant to get out of my comfort zone at first, but now I like it.
 What is it that bothers/annoy you exactly?
 
 I can't speak for Plessy, but the entire concept of using a different,
 much more limited patch system on top of git is just.. weird.  It makes
 absolutely no sense to dumb down all the rich metadata you have in your
 git repository to something that's possible to express using quilt.
 
 It's busywork that has very little value for anybody and a
 not-insignificant cost.

Got it now. And I agree. It'd be awesome if we had something like:
quilt git-cherry-pick git-ref

which would do the work. Then it wouldn't be a problem.

Also, it'd be super nice if someone gave a talk about git-dpm at
Debconf, to explain to everyone how it works. Anyone?

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c883b8.1060...@debian.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-16 Thread Johannes Schauer
Hi Charles,

Quoting Charles Plessy (2014-07-16 02:58:58)
 viewed from the opposite side of the chain, I have the impression that in
 most cases where I receive a report that package X does not build on
 architecture Y, it is a pure waste of time, since that package has no user
 base on that architecture.

while that package might have no user base, it might be required to build other
source packages on that architecture. You can easily check whether this is the
case by doing:

curl --silent http://bootstrap.debian.net/importance_metric_all.txt \
| awk '$1 == src:$yoursrcpkgname { print $3; }'

The number that is printed is the amount of other source packages which need
$yoursrcpkgname to be buildable so that they can be built on Debian sid amd64.
The file is regenerated daily.

So if you feel wookey becomes too eager you can tell him that not only do the
binary packages that $yoursrcpkgname builds have no users but it also is likely
not needed to build more source packages.

cheers, josch


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716060243.31130.14458@hoothoot



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-16 Thread Vincent Bernat
 ❦ 16 juillet 2014 09:58 +0900, Charles Plessy ple...@debian.org :

 Patch systems have a high importance in Debian because we accumulate patches
 that have little relevance for Upstream and the software's users.  One of the
 solution is to standardise the patch systems, but another solution is to stop
 producing patches that have no practical impact for the users.

What about patches that have a practical impact for the users, like
solving an important or a security bug?
-- 
printk(MASQUERADE: No route: Rusty's brain broke!\n);
2.4.3. linux/net/ipv4/netfilter/ipt_MASQUERADE.c


signature.asc
Description: PGP signature


Re: let missing-debian-source-format lintian tag be a warning!

2014-07-16 Thread Mathieu Parent (Debian)
Hi,

2014-07-16 3:36 GMT+02:00 Guillem Jover guil...@debian.org:
 Hi!

[...]
 Such warning might have made sense iff:

   - the new formats had been uncontroversial,

There is no such thing as being uncontroversial in Debian. There is
always somebody nitpicking when gaining hundred features and losing
one.

That's why we have some cdbs packages, dh7, dh7.
That's why we don't require Vcs-* fields.
That's why we still have some packages using dpatch
...

Oh, and I don't talk about systemd. Did I?

Mathieu Parent


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAFX5sbya3cU39Lo-2mEP=i-orscmhbd_b5xt-t7bhy4cmtr...@mail.gmail.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-16 Thread Raphael Hertzog
Hi,

On Wed, 16 Jul 2014, Guillem Jover wrote:
 The only reason for that warning right now is to pester people into
 either switching, which they should be doing out of their own
 volition anyway because people think the new formats are really
 superior and help them. Or so that people set it explicitly to 1.0
 just to shut up the warning, and then we have some kind of stats of
 how many people have been pestered… Which I think is the wrong way
 about trying to get people to switch.

You see it only from a negative side, sure there are a few people who
consider this message as pestering them but it really filled the role
of the missing lintian warning for all people who create source packages
from scratch and/or who take over old packages and use the lintian output
as their todo list.

Certainly that without this message the adoption rate of the new formats
would not have been so good as it has been (which despite some of the
critics, is probably one the best adoption rate for such wide scale opt-in
changes in the Debian history).

So to sum it up, I'm OK for dropping that message but only if lintian gets
the corresponding tag raised to a warning level and IMO it still makes
sense in the long term for dpkg-source to abort if debian/source/format is
missing, precisely because the historical default no longer matches
Debian's desired default.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716072051.gd3...@x230-buxy.home.ouaza.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-16 Thread Tollef Fog Heen
]] Thomas Goirand 

 On 07/15/2014 09:42 AM, Charles Plessy wrote:
  I am not a big fan of the 3.0 (quilt) format because it imposes a patch 
  system.
  In particular, this format does not make much sense when managing the source
  package with Git.
 
 I'm not sure I'm following you. I do use git for packaging, and I have
 no problem at all with format 3.0 (quilt). I was resisting to progress
 and reluctant to get out of my comfort zone at first, but now I like it.
 What is it that bothers/annoy you exactly?

I can't speak for Plessy, but the entire concept of using a different,
much more limited patch system on top of git is just.. weird.  It makes
absolutely no sense to dumb down all the rich metadata you have in your
git repository to something that's possible to express using quilt.

It's busywork that has very little value for anybody and a
not-insignificant cost.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738e1i2dg@xoog.err.no



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-16 Thread Russ Allbery
Tollef Fog Heen tfh...@err.no writes:

 I can't speak for Plessy, but the entire concept of using a different,
 much more limited patch system on top of git is just.. weird.  It makes
 absolutely no sense to dumb down all the rich metadata you have in your
 git repository to something that's possible to express using quilt.

 It's busywork that has very little value for anybody and a
 not-insignificant cost.

I used to feel this way, but have been slowly converting my own packages
over to use gbp pq.

The thing that made me change my mind was that I increasingly want to
share the patches, as clearly-defined, separate, upstreamable units, with
packages for other distributions and with upstream.

While it's possible to maintain artifacts in Git as used normally that
accomplish that end (such as by maintaining multiple topic branches), it's
actually quite complex and irritating, and those artifacts aren't then
exposed in the packaging system, and hence aren't readily available in
patch-tracker (when it's working).  I'm uninterested in quilt per se, and
am happy not to have to use it any longer, but the debian/patches *format*
is very nice for this purpose.  It exposes, as a packaging artifact,
high-quality, separated patches that can be considered and upstreamed
individually.  And now that there are good tools for managing those
artifacts without giving up the general usability of Git, I've been
convinced it's worth the additional effort.

It's still more work than just merging Git branches and using
single-debian-patch, so I'm not sure if I'll ever get to the point where I
do this with all of my packages.  But it has more merits than I saw
initially.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87iomxcchm@windlord.stanford.edu



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Mattia Rizzolo
On Tue, Jul 15, 2014 at 4:48 AM, Steve Langasek vor...@debian.org wrote:

Hi Steve,

 I understand not wanting to repackage the upstream tarball for source format
 1.0.  What I don't understand is why you *did* do this, instead of just
 switching the package to format 3.0 (quilt) as part of the update you were
 doing, or why you think a lintian warning would make any difference.

I didn't say which package I touched. It was part of a NMU, now
waiting for a possible ack by the maintainer. I don't feel well at
changing the source format in a NMU.
A proper lintian warning can enlighten the maintainer and push him
toward the change or somehow qualify the NMUer to add that file (if
there are no other big changes)

 https://wiki.debian.org/Projects/DebSrc3.0

 Well, this is a one-sided view of the question from the creator of the 3.0
 format, listing no disadvantages whatsoever.

Good. It's a wiki page, let's edit it. There is a
Advantages_of_new_formats section, you can add a
Disadvantages_of_new_formats or Advantages_of_old_format. Or list them
here. I'm really curios. As you can see I'm not an old or active or
deeply knowledged debian developer/maintainer, so I can miss
something.


-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAHKYmesAxMbq+=hs9kwqhdzqq86snzshk2rqorvjxcg7v3v...@mail.gmail.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Peter Palfrader
On Tue, 15 Jul 2014, Mattia Rizzolo wrote:

 A proper lintian warning can enlighten the maintainer and push him
 toward the change or somehow qualify the NMUer to add that file (if
 there are no other big changes)

There's no reason to have a debian/source/format in a classic debian
package.  The default is well defined.  I strongly oppose the idea of
having lintian complain about that even more.
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715081100.gl...@anguilla.noreply.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Raphael Hertzog
Hi,

On Tue, 15 Jul 2014, Mattia Rizzolo wrote:
  https://wiki.debian.org/Projects/DebSrc3.0
 
  Well, this is a one-sided view of the question from the creator of the 3.0
  format, listing no disadvantages whatsoever.
 
 Good. It's a wiki page, let's edit it. There is a
 Advantages_of_new_formats section, you can add a
 Disadvantages_of_new_formats or Advantages_of_old_format. Or list them
 here. I'm really curios. As you can see I'm not an old or active or
 deeply knowledged debian developer/maintainer, so I can miss
 something.

With all the enhancements made since its inception, I'm only aware of use
sensible use case that's not really possible with the new source format:
mixing quilt managed patches with non-managed changes typically created by
git cherry-pick. This is something that the X Strike Force does routinely
and that I never found the time to implement in the new source format.

Otherwise everybody mostly acknowledge that 3.0 (quilt) can provide the
same service as 1.0 with the --single-debian-patch option so I don't see
any reason to not increase the lintian tag to warning. The X team can put
1.0 in that file and keep using this format until we have a proper
solution for their use case and everybody else can have the required
reminder that they ought to use one of the newer formats by default.

If needed the tag description can be improved to mention the new option
for people who want to keep the old behaviour.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140715083449.gb14...@x230-buxy.home.ouaza.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Raphael Hertzog
On Tue, 15 Jul 2014, Peter Palfrader wrote:
 On Tue, 15 Jul 2014, Mattia Rizzolo wrote:
 
  A proper lintian warning can enlighten the maintainer and push him
  toward the change or somehow qualify the NMUer to add that file (if
  there are no other big changes)
 
 There's no reason to have a debian/source/format in a classic debian
 package.  The default is well defined.  I strongly oppose the idea of
 having lintian complain about that even more.

It depends on your definition of default. The historical default of dpkg
is well defined but it's no longer the default format used by Debian
maintainers since we have a very large majority of 3.0 (quilt):
http://upsilon.cc/~zack/stuff/dpkg-v3/

Keeping the historical default means that newcomers will keep doing the
mistake of creating 1.0 source packages when we want them to create
3.0 (quilt/native) packages.

What is so horrible in the idea of making an explicit choice of source
format?

Can we have a reasonable discussion based on real arguments and not on
personal feelings?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140715084305.gc14...@x230-buxy.home.ouaza.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Jonathan Dowland
On Tue, Jul 15, 2014 at 10:43:05AM +0200, Raphael Hertzog wrote:
 Can we have a reasonable discussion based on real arguments and not on
 personal feelings?

I haven't read any personal feelings yet, apart from personal preferences about
how to handle patches.

It *is* a shame that the patch-handling aspect of 3.0 (Quilt) is offputting
enough to folks that some are avoiding 3.0 altogether and not benefitting from
the other improvements. However the single-debian-patch workaround is a pretty
good compromise, IMHO, and perhaps just needs wider awareness.


-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715142628.ga9...@bryant.redmars.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Scott Kitterman
On Tuesday, July 15, 2014 15:26:28 Jonathan Dowland wrote:
 On Tue, Jul 15, 2014 at 10:43:05AM +0200, Raphael Hertzog wrote:
  Can we have a reasonable discussion based on real arguments and not on
  personal feelings?
 
 I haven't read any personal feelings yet, apart from personal preferences
 about how to handle patches.
 
 It *is* a shame that the patch-handling aspect of 3.0 (Quilt) is offputting
 enough to folks that some are avoiding 3.0 altogether and not benefitting
 from the other improvements. However the single-debian-patch workaround is
 a pretty good compromise, IMHO, and perhaps just needs wider awareness.

It seems to me 3.0 (Quilt) is still applying patches when the package is 
extracted using dpkg-source.  Is there a way to avoid that too?  That's been 
my major objection.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3190289.SmRNKVh7D1@scott-latitude-e6320



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Thomas Goirand
On 07/15/2014 09:42 AM, Charles Plessy wrote:
 I am not a big fan of the 3.0 (quilt) format because it imposes a patch 
 system.
 In particular, this format does not make much sense when managing the source
 package with Git.

I'm not sure I'm following you. I do use git for packaging, and I have
no problem at all with format 3.0 (quilt). I was resisting to progress
and reluctant to get out of my comfort zone at first, but now I like it.
What is it that bothers/annoy you exactly?

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c54a59.5010...@debian.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Andreas Metzler
Scott Kitterman deb...@kitterman.com wrote:
[...]
 It seems to me 3.0 (Quilt) is still applying patches when the
 package is extracted using dpkg-source.  Is there a way to avoid
 that too?  That's been my major objection.

dpkg-source -x --skip-patches foo.dsc
(Does not work in debian/source/options, though)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ng0g9b-oc1@argenau.downhill.at.eu.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Scott Kitterman
On Tuesday, July 15, 2014 18:12:41 Andreas Metzler wrote:
 Scott Kitterman deb...@kitterman.com wrote:
 [...]
 
  It seems to me 3.0 (Quilt) is still applying patches when the
  package is extracted using dpkg-source.  Is there a way to avoid
  that too?  That's been my major objection.
 
 dpkg-source -x --skip-patches foo.dsc
 (Does not work in debian/source/options, though)

Not adding debian/source/format gets me the same thing with less typing 
(although I appreciate knowing about the option, I'd missed that before).  If 
that worked in debian/source/options, then I don't think I'd have a strong 
reason to avoid 3.0 (Quilt).

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/16345713.7qspDBtfcA@scott-latitude-e6320



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Adam Borowski
On Tue, Jul 15, 2014 at 03:26:28PM +0100, Jonathan Dowland wrote:
 It *is* a shame that the patch-handling aspect of 3.0 (Quilt) is offputting
 enough to folks that some are avoiding 3.0 altogether and not benefitting from
 the other improvements. However the single-debian-patch workaround is a pretty
 good compromise, IMHO, and perhaps just needs wider awareness.

I wonder, what if we changed the meaning of no debian/source/format to 3.0
(quilt) + single-debian-patch?  Would anything break?

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715174543.ga16...@angband.pl



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Russ Allbery
Adam Borowski kilob...@angband.pl writes:
 On Tue, Jul 15, 2014 at 03:26:28PM +0100, Jonathan Dowland wrote:

 It *is* a shame that the patch-handling aspect of 3.0 (Quilt) is
 offputting enough to folks that some are avoiding 3.0 altogether and
 not benefitting from the other improvements. However the
 single-debian-patch workaround is a pretty good compromise, IMHO, and
 perhaps just needs wider awareness.

 I wonder, what if we changed the meaning of no debian/source/format to
 3.0 (quilt) + single-debian-patch?  Would anything break?

Yes: packages that are already using quilt with debian/patches and the 1.0
source format (perhaps because they don't want patches applied
automatically on unpack but instead want control of that in debian/rules
for one reason or another) would not play well with that change, since
both the existing quilt system and the 3.0 (quilt) source format want to
control and interpret debian/patches.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877g3eo6ex@windlord.stanford.edu



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Raphael Hertzog
Hi Scott,

On Tue, 15 Jul 2014, Scott Kitterman wrote:
 It seems to me 3.0 (Quilt) is still applying patches when the package is 
 extracted using dpkg-source.  Is there a way to avoid that too?  That's been 
 my major objection.

Can you elaborate on your objection?

Having patches applied by default is one of the main reasons why
people asked for a new source package format. It's very disconcerting for
most people to call dpkg-source -x and then not have the sources as they are
built by Debian.

Thus I believe that the current approach is the right one: apply by
default and let people with special needs use some options.

Can you agree with that? If not, can you explain why you don't agree?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140715190432.gc26...@x230-buxy.home.ouaza.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Raphael Hertzog
Hi,

On Tue, 15 Jul 2014, Jonathan Dowland wrote:
 It *is* a shame that the patch-handling aspect of 3.0 (Quilt) is offputting
 enough to folks that some are avoiding 3.0 altogether and not benefitting from
 the other improvements. However the single-debian-patch workaround is a pretty
 good compromise, IMHO, and perhaps just needs wider awareness.

What is so offputting? Is it quilt itself?

If quilt is the problem, aren't you more satisfied with tools like gbp-pq
that lets you avoid quilt and use (rebased) git branches to manage the
quilt series?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140715190718.gd26...@x230-buxy.home.ouaza.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Scott Kitterman
On Tuesday, July 15, 2014 21:04:32 Raphael Hertzog wrote:
 Hi Scott,
 
 On Tue, 15 Jul 2014, Scott Kitterman wrote:
  It seems to me 3.0 (Quilt) is still applying patches when the package is
  extracted using dpkg-source.  Is there a way to avoid that too?  That's
  been my major objection.
 
 Can you elaborate on your objection?
 
 Having patches applied by default is one of the main reasons why
 people asked for a new source package format. It's very disconcerting for
 most people to call dpkg-source -x and then not have the sources as they are
 built by Debian.
 
 Thus I believe that the current approach is the right one: apply by
 default and let people with special needs use some options.
 
 Can you agree with that? If not, can you explain why you don't agree?

It's perhaps just my mental model of the way packaging works.  You have the 
upstream part and the Debian part.  When you unpack a package, the Debian part 
is in the Debian directory.  The upstream part is not.

If patches are applied on extraction, this separation is violated and seems to 
me fundamentally wrong.  If the majority of the project doesn't see it that 
way and chooses not to care/want patches applied, then I don't seek to 
overturn that.  

It would be nice, however, to have a way to specify the alternate behavior in 
a consistent reliable way (meaning something I can put in the package when I 
add source/format).

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1484304.9BRKLAu1OC@scott-latitude-e6320



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Barry Warsaw
On Jul 15, 2014, at 12:37 PM, Scott Kitterman wrote:

On Tuesday, July 15, 2014 18:12:41 Andreas Metzler wrote:
 Scott Kitterman deb...@kitterman.com wrote:
 [...]
 
  It seems to me 3.0 (Quilt) is still applying patches when the
  package is extracted using dpkg-source.  Is there a way to avoid
  that too?  That's been my major objection.
 
 dpkg-source -x --skip-patches foo.dsc
 (Does not work in debian/source/options, though)

Not adding debian/source/format gets me the same thing with less typing 
(although I appreciate knowing about the option, I'd missed that before).  If 
that worked in debian/source/options, then I don't think I'd have a strong 
reason to avoid 3.0 (Quilt).

Should it though?  Isn't to apply or not apply patches automatically a
preference of the individual developer rather than of the package?
Especially for team maintained packages, if you and I are on a team, you might
not want it to apply patches but I might.

I suppose in those cases though, teams (or even co-maintainers) can establish
conventions, although it would be nice in that case to also have a
--no-skip-patches option.

Cheers,
-Barry


signature.asc
Description: PGP signature


Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Barry Warsaw
On Jul 15, 2014, at 09:07 PM, Raphael Hertzog wrote:

If quilt is the problem, aren't you more satisfied with tools like gbp-pq
that lets you avoid quilt and use (rebased) git branches to manage the
quilt series?

My one experience with this was not very successful, although I'm sure it was
pebkac, and yes I should have filed actual bugs if I found them (but was under
a crunch at the time).

IIRC, where I would normally apply a quilt patch, edit the file, and refresh
the patch, I always ended up with every modification as a separate d/patches
file, even though I thought I was rebasing it correctly.

Oh well - I'm curmudgeonly pretty comfortable with the svn-buildpackage set of
tools and workflows, which the DPMT still prefers.  I need to play more with
gbp and git-dpm, the latter which IIRC felt smoother.  Is there any emerging
consensus on which of the two git-based package development regimes is
better or more popular?

Cheers,
-Barry


signature.asc
Description: PGP signature


Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Adam Borowski
On Tue, Jul 15, 2014 at 10:53:10AM -0700, Russ Allbery wrote:
 Adam Borowski kilob...@angband.pl writes:
  On Tue, Jul 15, 2014 at 03:26:28PM +0100, Jonathan Dowland wrote:
  It *is* a shame that the patch-handling aspect of 3.0 (Quilt) is
  offputting enough to folks that some are avoiding 3.0 altogether and
  not benefitting from the other improvements. However the
  single-debian-patch workaround is a pretty good compromise, IMHO, and
  perhaps just needs wider awareness.
 
  I wonder, what if we changed the meaning of no debian/source/format to
  3.0 (quilt) + single-debian-patch?  Would anything break?
 
 Yes: packages that are already using quilt with debian/patches and the 1.0
 source format (perhaps because they don't want patches applied
 automatically on unpack but instead want control of that in debian/rules
 for one reason or another) would not play well with that change, since
 both the existing quilt system and the 3.0 (quilt) source format want to
 control and interpret debian/patches.

I checked: it looks like 1050 (!) source packages use the 1.0 format _and_
have a debian/patches directory.  Suffering both 1.0 and quilt... the worst
of both worlds.  Scary!

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715221941.ga20...@angband.pl



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Michael Gilbert
On Tue, Jul 15, 2014 at 3:50 PM, Scott Kitterman wrote:
 It would be nice, however, to have a way to specify the alternate behavior in
 a consistent reliable way (meaning something I can put in the package when I
 add source/format).

Archive consistency is far more important than individual maintainer
preference about this behavior.  People that work on lots of different
packages deserve dpkg-source to act consistently across the entire
archive.

This would be far better solved with a system conffile of some sort
like /etc/dpkg/dpkg-source.cfg, which admittedly doesn't exist yet.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANTw=MPWsRUi0Lw29s3H7Vh1+_4p=c2kovlge81ytcb8yv9...@mail.gmail.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Mattia Rizzolo
On Wed, Jul 16, 2014 at 12:39 AM, Michael Gilbert mgilb...@debian.org wrote:
 This would be far better solved with a system conffile of some sort
 like /etc/dpkg/dpkg-source.cfg, which admittedly doesn't exist yet.

in general I feel the lack of a $HOME/.dpkg.conf conffile...
Luckily there are wrappers (debuild?) that take care of passing the
options I want to dpkg-* programs.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymeshprn-t80jc+6s+3f+dmskeswtuonupxmzypk+gey...@mail.gmail.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Matthias Klumpp
2014-07-16 0:44 GMT+02:00 Mattia Rizzolo mat...@mapreri.org:
 On Wed, Jul 16, 2014 at 12:39 AM, Michael Gilbert mgilb...@debian.org wrote:
 This would be far better solved with a system conffile of some sort
 like /etc/dpkg/dpkg-source.cfg, which admittedly doesn't exist yet.

 in general I feel the lack of a $HOME/.dpkg.conf conffile...
 Luckily there are wrappers (debuild?) that take care of passing the
 options I want to dpkg-* programs.
That config file sounds like a really great idea to suit everyone.
With something like that in place and the one-patch solution for
people who want to maintain their patches differently, there shouldn't
be disadvantages of switching to 0.3 (quilt), or am I missing some?
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caknhny9krwn50g4xxg5bzxq8kgqw5b4k84n2yrgszrwcb-r...@mail.gmail.com



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Wookey
+++ Michael Gilbert [2014-07-15 18:39 -0400]:
 On Tue, Jul 15, 2014 at 3:50 PM, Scott Kitterman wrote:
  It would be nice, however, to have a way to specify the alternate behavior 
  in
  a consistent reliable way (meaning something I can put in the package when I
  add source/format).
 
 Archive consistency is far more important than individual maintainer
 preference about this behavior.  People that work on lots of different
 packages deserve dpkg-source to act consistently across the entire
 archive.

I would strongly second this view. As a porter it is a very good thing
thing that all quilt/3.0 packages behave the same way, whatever the
maintainer's preferences. Having some aply patches and some not, would
just be yet another source of random oddness in packages, and we have
more than enough of that already.

 This would be far better solved with a system conffile of some sort
 like /etc/dpkg/dpkg-source.cfg, which admittedly doesn't exist yet.

Agreed. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716001905.gk22...@stoneboat.aleph1.co.uk



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Colin Watson
On Tue, Jul 15, 2014 at 10:42:15AM +0900, Charles Plessy wrote:
 Le Tue, Jul 15, 2014 at 03:26:30AM +0200, Mattia Rizzolo a écrit :
  In fact I'm wondering what is the rationale to stay with the 1.0 format, 
  given
  all the benefits of the 3.0 (quilt) format:
 
 Hi Mattia,
 
 I am not a big fan of the 3.0 (quilt) format because it imposes a patch 
 system.
 In particular, this format does not make much sense when managing the source
 package with Git.

Having followed it up after last year's DebConf, I've been absolutely
sold on git-dpm, FWIW; I find it does a great job of making the patch
queue pleasant to maintain in a git-native style while providing a nice
easy-to-read export to 3.0 (quilt) - that is, you don't actually use
quilt manually.  At that point 3.0 (quilt) makes a lot of sense to me as
an automatable serialisation of upstream + patch queue + packaging with
a minimum of package-specific code, and the only way in which it imposes
a patch system is that the tools I'm using need to export to it (which
is really not that much more than git format-patch with some care about
file names, so no big deal, and people can still inspect and modify my
source packages without my fancy tools).

Getting my head around git-dpm was the tipping point for me to spend
some time converting my packages out of bzr or older systems, and now I
find myself actively seeking out things I can do with it, which seems to
me to be a quite remarkable property in this sort of tool especially
given that I started out not being desperately fond of git.  And I was
going to need some kind of patch queue against upstream in many cases
anyway, so it's not as though it adds some new overhead that I wouldn't
have had to care about without 3.0 (quilt).  A good number of my
packages are now just fancy branches of upstream's git repository, which
is IMO right and proper.

gbp-pq is of course fairly similar.  I looked at both although I admit
that I only experimented extensively with git-dpm.  They both look like
they should get the job done, but git-dpm just seemed more featureful
and polished to me based on its documentation, and I really like the way
it handles the results of rebasing the patch queue.

For completeness, the only downsides I've encountered after six months
or so of using git-dpm are:

 * If you have a big patch queue then it can create rather a lot of
   commits, since changes deep in the queue cause everything after them
   to be rebased and the tip of the rebased branch merged into master.
   This is fine in gitk or similar, and it's a clever and useful way to
   keep track of various versions of a rebasing branch while keeping the
   end result fast-forwarding, but it can be a little puzzling in things
   like a gitweb shortlog.

 * It (perhaps necessarily?) doesn't quite do an exact round-trip of
   debian/patches/ when you first convert to it, since it exports
   patches using git format-patch and so changes the format of patch
   headers a bit.  I decided that I didn't find the changes
   objectionable for my own packages, but it's not entirely obvious how
   things would work if you were to try to make this scheme work for all
   3.0 (quilt) packages in dgit, where you want to make sure to
   round-trip cleanly.

 * Not really git-dpm's fault, but the bug fixed in
   http://www.spinics.net/lists/git/msg234123.html caused some confusion
   on a couple of occasions when rebasing against new upstream releases.

Anyway, worth a look if you haven't already.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716003504.ga28...@riva.ucam.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Charles Plessy
Le Wed, Jul 16, 2014 at 01:19:05AM +0100, Wookey a écrit :
 +++ Michael Gilbert [2014-07-15 18:39 -0400]:
  On Tue, Jul 15, 2014 at 3:50 PM, Scott Kitterman wrote:
   It would be nice, however, to have a way to specify the alternate 
   behavior in
   a consistent reliable way (meaning something I can put in the package 
   when I
   add source/format).
  
  Archive consistency is far more important than individual maintainer
  preference about this behavior.  People that work on lots of different
  packages deserve dpkg-source to act consistently across the entire
  archive.
 
 I would strongly second this view. As a porter it is a very good thing
 thing that all quilt/3.0 packages behave the same way, whatever the
 maintainer's preferences. Having some aply patches and some not, would
 just be yet another source of random oddness in packages, and we have
 more than enough of that already.

Hi Wookey,

viewed from the opposite side of the chain, I have the impression that in most
cases where I receive a report that package X does not build on architecture Y,
it is a pure waste of time, since that package has no user base on that
architecture.

Patch systems have a high importance in Debian because we accumulate patches
that have little relevance for Upstream and the software's users.  One of the
solution is to standardise the patch systems, but another solution is to stop
producing patches that have no practical impact for the users.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716005858.gg21...@falafel.plessy.net



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Guillem Jover
Hi!

On Tue, 2014-07-15 at 18:39:14 -0400, Michael Gilbert wrote:
 On Tue, Jul 15, 2014 at 3:50 PM, Scott Kitterman wrote:
  It would be nice, however, to have a way to specify the alternate behavior 
  in
  a consistent reliable way (meaning something I can put in the package when I
  add source/format).
 
 Archive consistency is far more important than individual maintainer
 preference about this behavior.  People that work on lots of different
 packages deserve dpkg-source to act consistently across the entire
 archive.

Exactly. I don't have any intention to change the current dpkg-source
default behavior in that regard.

 This would be far better solved with a system conffile of some sort
 like /etc/dpkg/dpkg-source.cfg, which admittedly doesn't exist yet.

But sure, that (and its $HOME counterpart) is a good idea and is
something I'll be adding (possibly for 1.17.12) when also adding
config file support for dpkg-buildpackage.

Coincidentally I've actually been looking very recently into cleaning
up the command-line parsing code in dpkg-source to make, for example,
--help output all format specific options, which I'll have to fix
anyway to not output pestering warnings when using format specific
options from a config file on the “wrong” source format. Arguably the
problem exists already today, if one wants to use the same options w/o
knowing what source format is being unpacked.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716010817.ga13...@gaara.hadrons.org



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-15 Thread Guillem Jover
Hi!

On Tue, 2014-07-15 at 10:11:00 +0200, Peter Palfrader wrote:
 On Tue, 15 Jul 2014, Mattia Rizzolo wrote:
  A proper lintian warning can enlighten the maintainer and push him
  toward the change or somehow qualify the NMUer to add that file (if
  there are no other big changes)
 
 There's no reason to have a debian/source/format in a classic debian
 package.  The default is well defined.  I strongly oppose the idea of
 having lintian complain about that even more.

In addition, currently dpkg-source emits a warning when there's no
debian/source/format file present, and that's something that has been
bothering me for a while and something I think I'll be changing (i.e.
shutting up the warning).

Such warning might have made sense iff:

  - the new formats had been uncontroversial,
  - source 1.0 packages could be automatically switched safely,
  - and we'd have decided that format 1.0 is deprecated,

in which case we should just have switched the default, but none of
the above has been the case.

The only reason for that warning right now is to pester people into
either switching, which they should be doing out of their own
volition anyway because people think the new formats are really
superior and help them. Or so that people set it explicitly to 1.0
just to shut up the warning, and then we have some kind of stats of
how many people have been pestered… Which I think is the wrong way
about trying to get people to switch.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716013640.gb13...@gaara.hadrons.org



let missing-debian-source-format lintian tag be a warning!

2014-07-14 Thread Mattia Rizzolo
Yesterday I touched another package without the debian/source/format file.
It was sad: I had to repackage the entire upstream tarball to switch from .xz to
.gz only to make dpkg happy and recognize it as non-native.
For me this is a nonsense.

Lintian has a info tag for this for a lot of time:
http://lintian.debian.org/tags/missing-debian-source-format.html and in fact the
package without that file are decrasing, but very slowly, making unnecessary
difficult to contribue for prospective new contributers, and in the long term
really deprecating the source format 1.0.

Someone opened a bug against lintian: https://bugs.debian.org/702671 and I rised
myself this concern to lintian maintainers, but it turn out that there are
people that does not want lintian to be too pedantic nor to be forced to do as a
simple thing as adding a 10-bytes file to their debian packages.
In fact I'm wondering what is the rationale to stay with the 1.0 format, given
all the benefits of the 3.0 (quilt) format:
https://wiki.debian.org/Projects/DebSrc3.0

So, I would like to see what is the collective idea of the debian developers as
a whole (or something like that, given that there not so much active developers
in this ML, compared to the active people).

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me:  http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page:   https://wiki.ubuntu.com/MattiaRizzolo


signature.asc
Description: Digital signature


Re: let missing-debian-source-format lintian tag be a warning!

2014-07-14 Thread Charles Plessy
Le Tue, Jul 15, 2014 at 03:26:30AM +0200, Mattia Rizzolo a écrit :
 
 In fact I'm wondering what is the rationale to stay with the 1.0 format, given
 all the benefits of the 3.0 (quilt) format:

Hi Mattia,

I am not a big fan of the 3.0 (quilt) format because it imposes a patch system.
In particular, this format does not make much sense when managing the source
package with Git.

This said, adding “single-debian-patch” in debian/source/options makes the 3.0
(quilt) format emulate the 1.0 format quite well, while keeping the benefits of
the 3.0 format family, in particular having the debian directory in a separate
tarball, and supporing xz compression for the original upstream tarball.

So on my side, if the single-debian-patch workaround is widely accepted (in
debian/source/options, not debian/source/local-options), then I would not mind
the 1.0 format to go away.

This said, even the 3.0 (quilt) format is starting to show its age.  We need to
be ready for the post-tarball era…

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715014215.gd21...@falafel.plessy.net



Re: let missing-debian-source-format lintian tag be a warning!

2014-07-14 Thread Steve Langasek
Hi Mattia,

On Tue, Jul 15, 2014 at 03:26:30AM +0200, Mattia Rizzolo wrote:
 Yesterday I touched another package without the debian/source/format file.
 It was sad: I had to repackage the entire upstream tarball to switch from .xz 
 to
 .gz only to make dpkg happy and recognize it as non-native.
 For me this is a nonsense.

 Lintian has a info tag for this for a lot of time:
 http://lintian.debian.org/tags/missing-debian-source-format.html and in fact 
 the
 package without that file are decrasing, but very slowly, making unnecessary
 difficult to contribue for prospective new contributers, and in the long term
 really deprecating the source format 1.0.

I understand not wanting to repackage the upstream tarball for source format
1.0.  What I don't understand is why you *did* do this, instead of just
switching the package to format 3.0 (quilt) as part of the update you were
doing, or why you think a lintian warning would make any difference.

The biggest reason for maintainers to have not migrated to 3.0 (quilt) is
that it's additional work with no immediate benefit.  If they don't have
patches against the upstream source, it's an easy conversion but provides
little benefit for the current version.  If they do have patches against the
upstream source, there's a more obvious benefit (standardization of patch
systems) but it makes the conversion non-trivial.

A new upstream version that provides its sources using a compression format
that's incompatible with 1.0 is the obvious opportunity to switch to 3.0.

Of course, in the absence of a 3.0 (quilt) switch, there's still no reason
to repack the tarball; the only thing you'd need to do is recompress it
(unxz; gunzip).

 Someone opened a bug against lintian: https://bugs.debian.org/702671 and I
 rised myself this concern to lintian maintainers, but it turn out that
 there are people that does not want lintian to be too pedantic nor to be
 forced to do as a simple thing as adding a 10-bytes file to their debian
 packages.  In fact I'm wondering what is the rationale to stay with the
 1.0 format, given all the benefits of the 3.0 (quilt) format:
 https://wiki.debian.org/Projects/DebSrc3.0

Well, this is a one-sided view of the question from the creator of the 3.0
format, listing no disadvantages whatsoever.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature