[SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-41-g15d16a4
Jonas Smedegaard
dr at jones.dk
Sun Apr 4 19:29:21 UTC 2010
On Sun, Apr 04, 2010 at 09:03:19PM +0200, Reinhard Tartler wrote:
>On Sun, Apr 04, 2010 at 11:04:11 (CEST), Jonas Smedegaard wrote:
>
>>>Is it really too much that simple things like 'build && clean' leave
>>>a 'clean' working directory?!
>>
>> I believe that I could make a CDBS snippet that cleans up patches and
>> .pc dir at clean time when in a git.
>>
>> Applying the patches at build time should not be necessary, as dpkg
>> handles that itself.
>>
>> Such snippet - like most of CDBS - would *not* depend on CDBS
>> managing debhelper too, so should be usable also together with
>> short-form debhelper v7.
>>
>> I believe that would help the point of usability, as then only once
>> initially something odd would need doing. Would that be interesting?
>
>This sounds like a great idea to me. In essence, this restores the old
>invariant that running 'debclean' restores a working directory that is
>ready to be worked on with VCS commands.
>
>Moreover, this approach "if (and only if) in a vcs, unapply and remove
>.pc", could (and probably should) be implemented in other clean rules
>(read: non-cdbs managed packages) as well.
>
>With this invariant, I can imagine to work on "Format 3.0 (quilt)"
>packages.
Very well. I will have a look at implementing such hack, then.
>>> Side note, I see that there are some really interesting cdbs make
>>> snippets, e.g., the upstream.mk rules etc. I understand that they
>>> are still pretty much in flux. Could you imagine to propose a
>>> stabilized version (or a subset of them) for dpkg-dev?
>>
>> It seems to me that dpkg-dev is Perl-based. CDBS is make-based, so
>> as I see it dpkg-dev could adopt ideas only, not actual
>> implementation.
>
>Hm, scripts/licensecheck2dep5 is perl. As it is implemented as a
>wrapper around licensecheck, perhaps it should be submitted for the
>devscripts package? Or even integrated into the licensecheck script
>itself?
>
>AFAIUI, it is not intended to be used directly; instead,
>copyright-check.mk uses it. TBH, I don't understand why you didn't
>implement all of the debian/stamp-copyright-check in
>scripts/licensecheck2dep5. Since this target does not really
>contribute to the actual building of packages, I don't see why you
>implemented it in cdbs in the first place. To me, I feel this rather
>belongs into the devscripts package and shouldn't be run via
>debian/rules but directly via some dedicated helper tool by the
>packager.
Yeah, true. That one piece is Perl. And I really should merge that
script into licensecheck itself. Just haven't taken the time and social
endurance yet to figure out how that package is maintained, whom to
discuss with if ok that I start hack on it to improve it, and how many
different opinions I need to challenge and argue against regarding Perl
coding style, intend of that tool etc. etc. etc.
Just see how much time we've spent arguing about packaging style here.
No, I am not whining, just stating the fact that it takes time and
effort to get involved in yet another development team.
So that one hack is Perl but irrelevant for dkpg-dev. And other parts
are not Perl so irrelevant for dpkg-dev too. As I see it.
Please keep challenge me on that, though :-)
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100404/4908dc57/attachment-0001.pgp>
More information about the pkg-multimedia-maintainers
mailing list