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
> >
> > 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 

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 

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 

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

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to