[SCM] bumblebee/master: Add rules file simplification changes made by Ralf Jung, thanks!

[Vincent Cheng]

On Mon, Mar 18, 2013 at 12:34 AM, Andreas Beckmann <anbe at debian.org> wrote:
> On 2013-03-18 08:15, Vincent Cheng wrote:
>> On Mon, Mar 18, 2013 at 12:07 AM, Andreas Beckmann <anbe at debian.org> wrote:
>>> On 2013-03-18 07:58, vincentc-guest at users.alioth.debian.org wrote:
>>>>  override_dh_auto_install:
>>>>       dh_auto_install --destdir=debian/bumblebee/
>>>
>>> with only these two lines remaining, override_dh_auto_install can be
>>> removed completely, as that is the default
>>
>> src:bumblebee builds several binary packages however. Doesn't
>> dh_auto_install dump everything in debian/tmp in that case?
>
> correct
>
> from just looking at the diff I concluded differently ...
>
> And with the followup commit
>
>>     Whoops, the last commit added a bunch of new conffiles which I'm
> not sure is the right thing to do, so revert for now
>
> I recommend to
> * get rid of the override target
> * have it install to debian/tmp
> * use bumblebee.install (mv install bumbelbee.install) to put things
> into the correct place

(I think) the reason why upsteam opted to install everything directly
into debian/bumblebee instead of dumping everything in debian/tmp
first and using dh_install to cherrypick files into the right package
is because everything that gets installed by the makefile's install
target is going to go inside the binary package "bumblebee" anyways,
hence it's just easier to tell dh to install everything into
bumblebee's build directory from the get-go. (bumblebee-nvidia is an
empty binary package to deal with glx diversions in the maintainer
scripts, bumblebee-dbg has nothing but debug symbols). Why add the
extra complexity of moving files from debian/tmp to debian/bumblebee
when you know that everything's going to go inside bumblebee's build
directory in the end?

> also rename the maintainer scripts from p* to bumblebee.p*
> having both package-qualified and not qualified files in debian for the
> same package is confusing, and unqualified ones are discouraged for
> multi-binary packages

Agreed. I'll try to push upstream to rename their maintainer scripts as well.

Regards,
Vincent