[Pkg-fglrx-devel] Bug#636450: Bug#636450: closed by Michael Gilbert <michael.s.gilbert at gmail.com> (Bug#636450: fixed in fglrx-driver 1:11-7-3)

Michael Gilbert michael.s.gilbert at gmail.com
Sat Aug 6 19:44:28 UTC 2011


Andreas Beckmann wrote:

>   * a different solution for fglrx-libglx.so that avoids renaming is to
>     modify glx-alternative-fglrx. if you would prefer this, I can make
>     the neccessary changes there

Hi,

Yes, actually this solution is far more preferable.  I had wanted to
stick with the upstream file naming but wasn't sure what it would take
to do that.  Changing glx-alt-fglrx just seems like the right thing to
do.

> 21-remove-redundant-package-name-from-lintian-overrides.diff
>   * the package name in debian/*.lintian-overrides is redundant
>     information - so remove this to simplify package splitting and
>     renaming

Looks good.  Please go ahead and commit.
 
> 22-wildcard-lintian-overrides.diff
>   * I'd suggest to just use wildcards for the most common overrides:
>     spelling-error-in-binary and source-contains-prebuilt-binary
>     instead of listing every occurrence

I think you attached the wrong patch here.

> 23-use-DEB_HOST_ARCH-and-prepare-multiarch-support.diff
>   * DEB_BUILD_ARCH is the wrong decision point, it's not neccessarily
>     the target architecture, use DEB_HOST_ARCH instead
>   * also this variable needs to be initialized
>   * while we are at it, get DEB_HOST_MULTIARCH, too and add a
>     substitution variable _LIBDIR_ which will get a value of
>     usr/lib (without MULTIARCH) or usr/lib/$(DEB_HOST_MULTIARCH)

I don't see why this is needed.  If it improves multiarch support, I
think it would be better to roll that into the changes for that.

Why is this needed?
+
+generated: $(generated) ;

> Some general style suggestion: in Makefiles for $(shell ...) and
> $(wildcard ...) evaluations I usually prefer single expansion
> (var := $(shell ...)) if possible. otherwise each evaluation of the
> variable runs the command again and again

This only really affects build time ever so slightly.  I would prefer
to stick with the current style; being more
discoverable/straightforward; at least in my opinion.

Thanks so much with your help on these issues!

Best wishes,
Mike





More information about the Pkg-fglrx-devel mailing list