On 11-06-12 at 11:18am, Dan S wrote: > 2011/6/11 Jonas Smedegaard <d...@jones.dk>: > > This looks bad: > > > >> # The build system apparently can't handle this > >> CXXFLAGS = > > > > That and the DEB_SCONS_OPTIONS above it seems to indicate that it > > does not follow Debian Policy §4.9.1. Only a recommendation > > apparently, but I am uncertain if that only is _how_ to do it (i.e. > > DEB_BUILD_OPTIONS hinting) while the underlying mechanisms (e.g. > > ability to build without optimizations or without stripping > > binaries) is a must. > > This is reasonable -- there's about to be a minor upstream release so > I'll try and patch upstream (even though it's a debianny issue), to > parse DEB_BUILD_OPTIONS.
That is bad approach! I strongly recommend against optimizing specifically for Debian needs upstream. Instead, optimize upstream in _generic_ ways and let each distro use those generic hooks however they see fit. Concretely, I recommend to fix upstream the handling of custom CXXFLAGS if indeed that is broken. Core variables like that (and also LDFLAGS etc.) should be overridable at compile time. > > Oh, and why do editor plugins recommend -doc package? Seems they > > are tools to write code, not closely related to the documentation of > > the tool, so should perhaps be lowered to a suggestion. > > I see your reasoning. Well, the documentation is not completely > independent - the editor-plugins include "jump to the help for this > command"-type features, and if the -doc is missing we get confused > users asking why the help-feature is broken. My inclination is for > Recommends here, for that reason - sounds OK? Yes, sounds sensible. But then mention in the long description that reasoning for the relation. Oh, and while at it, drop from the long description the comment on where the README file is located. Purpose of long description is to help the user decide what is relevant to install - and in that context it is not sensible to tell info on how to use it (and location of README is common for _all_ packages in Debian). > > And I guess main packages not suggest/recommend -doc package too. > > Sorry, what do you mean? You're saying perhaps that supercollider > should Suggest supercollider-doc? That sounds sensible. Yes, that's what I meant. Thanks for bypassing my words and instead reading my mind :-) > > What is the most proper build-dependency for jack these days? Here > > it is "libjack-dev (>= 0.100) | libjack-jackd2-dev", which as I > > believe is not wrong but seem to recall can be satisfied by a > > simpler dependency. > > Ah right, the version 2 package is marked as "Provides: libjack-dev" > so we can simplify the dependency to "libjack-dev (>= 0.100)". I > remember there being a reason for keeping both - but it might have > been for earlier versions, before that particular "Provides" was in > place. No, that won't work: virtual packages do not satisfy a versioned dependency. I believe you can simply use "libjack-dev". As I recall, the (obsolete, I believe) reason for the versioning was introduction of new features - before jackd2 was introduced, and adding jackd2 as alternative was a temporary hack until things like that virtual package hint was sorted out. > > The clean rule does not fully cleanup. These files was left behind: > > > > common/.sconf_temp/ > > common/.sconsign.dblite > > common/config.log > > I don't see this behaviour. (The clean rule contains an explicit "rm > -f common/.sconsign.dblite" so I'm not sure how it would happen.) > Could you give me the full commands to reproduce please? Oh - ignore that one, it was my own fault: I had left some noise in the rules file when I did the copyright investigation - that was the reason for the clean process to fail. :-P - 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
