On Sun, Apr 04, 2010 at 12:25:02PM +0200, Adrian Knoth wrote:
On Fri, Apr 02, 2010 at 01:30:21AM +0200, Jonas Smedegaard wrote:
Is it ok with you that I repackage from the current vcs-tarball to pristine-(or-repackaged)-tarball + vcs-patch?I'm not sure if I'm qualified to give an answer that respects all implications of this question. I also don't understand half of the quilt-gbp discussion, so I have to rely on the assumption that you know what you're doing. ;)
Thanks for pointing out some things that you cannot follow of the routines that I do: That helps me know what need clarified :-D
So let me try elaborate on the implications of my question, to help you make a qualified decision if you agree on it or not:
The question is separate from that other discussion about Git packaging style and its clashing with the use of dpkg source format "3.0 (quilt)".
The issue here, as I see it, has 2 implications: a) Basing our packaging on upstream tarballs or only on upstream VCS b) Having me do any of the packaging workRegarding a) this has been discussed in detail recently on the list. Here I will summarise as a proposed new policy for this team:
1. Use upstream tarball when possible.2. When impossible due to no upstream tarball at all, discuss first in the team if this should be packaged at all, as that often indicates a frequently moving target, which either might be unfit for redistribution or perhaps needs special care (e.g. overriding shared/static library handling).
3. When "impossible" due to major changes since last tarball release
and current VCS, discuss first in the team, as there is a high
risk of accidentally releasing too experimental code.
Since problems have been discovered in the currently prepared packaging
by you, requiring a repackaging, it makes sense to bring up the question
now for this specific package.
Since TTBOMK there is no current team policy conflicting with above proposed one, I see no need to discuss that proposal before applying it to this specific package.
So regarding a) I believe it boils down to a guestion of whether or not you will find it annoying that I isolate the changes between latest upstream tarball and the VCS snapshot that you prepared, and include that difference as a patch?
Regarding b) that other ongoing discussion touched the general concern of complicating maintainance in this team by having multiple packaging styles. I have a strong opinion about CDBS vs. short-form debhelper 7 and insist on aggressively use CDBS while _avoiding_ short-form debhelper 7. This has already affected simplicity of packaging in this team, and it is a relevant question if the team is better off without me.
There is a common misunderstanding about CDBS that it is targeted beginners, and helps hide complicated parts of packaging. That is IMO wrong, and even dangerous: CDBS is better seen as a tool for advanced packaging. When I claim that CDBS is easy to use (and I do claim that) then I do *not* mean that it is possible to avoid understanding what is going on during the packaging process, only that you need not explicitly declare all the tedious parts of it but can use a CDBS templating snippet for most if not all of it. YOU ARE STILL RESPONSIBLE for what you let CDBS do for you.
So if a goal of the Multimedia team is to keep a low entry bar for new developers, and to keep all packages equally easy for new developers to engage in maintaining, then perhaps you should avoid CDBS and only use debhelper.
I say "perhaps" because I really do not know the parts of debhelper trying do reinvent the wheel of make - those enabled in short-form mode. And I have no interest in learning, because I fundamentally find it a wrong approach. Maybe some day when everyone else in Debian have abandoned CDBS and Debian Policy changed to not have debian/rules be a make file but a debhlper config file, I might change my mind, but currently I cannot imagine that happen.
So I guess b) boils down to a question if you will allow me to infest the JACK packaging with even more CDBS now, potentially making it cumbersome to change later when maybe the team decides to avoid CDBS?
In other words: if you say that tarball+vcs-patch is the right way to address all the copyright issues in the jackd2 package, then go ahead.
Define "right way". It certainly is "my way" :-)
jackd2-1.9.6 will probably contain most of the things we need, that is, ffado port naming and manpages. ;)
...meaning either a) I am silly to waste my time on this since it is soon irrelevant (but hey - why bother, it is my time, pride and stubbornness, not yours), or b) you can simply delay answering my question until upstream at some point release that new version as a tarball.
Could give a little hint how to repackage/strip new upstream versions, so more than one person in the team knows how to do it? ;)
Most certainly: dch -bv 1.9.5-1 debian/rules get-orig-sourceVoila - that should give you a tarball repackaged from pristine source, below ../tarballs/
That was the ultra-short version. Please clone calf (debcheckout calf) and read debian/README.source for the longer version. And please do propose improvements to that text (it is reused across 50-80 packages).
Yes, I no that it is inelegant to need to manually edit the version number, but that's the state of affairs currently. Ideas for improvements to the get-orig-source routine are most welcome :-)
Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
