Merge lp:~andrewsomething/xscreensaver/bug-385850 into lp:~ubuntu-desktop/xscreensaver/ubuntu

Debian maintainer proposed a cleaner version of the script I wrote that was included in the last commit. This converts to using that script while maintaining the reduction of screensavers installed.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539937

It would be nice if you filled in a comment in split-hacks.config for those hacks that you move to *-extra in Ubuntu. For those hacks which are moved because of performance issues, a bug reference is most welcome.

This will make it easier to evaluate these changes and possibly include them in Debian as well.

Looks a lot simpler to me. Some feedback:
- It would be nice to echo something while each hack is being packaged. Currently building with this branch uses a lot of CPU and doesn't provide any feedback as to which hack is being built.
- For readability I'd list the hacks in split-hacks.conf like this:
# Default screensavers
(xscreensaver-data hacks)
(xscreensaver-gl hacks)

# Optional screensavers
(xscreensaver-data-extra hacks)
(xscreensaver-gl-extra hacks)

# Broken screensavers
(xscreensaver-data-extra hacks)
(xscreensaver-gl-extra hacks)

a) Don't know if the current script will handle comments like this
b) This will make it harder to do a simple merge between Debian and Ubuntu but I think this is better than commenting on each one

> Looks a lot simpler to me. Some feedback:
> - It would be nice to echo something while each hack is being packaged.
> Currently building with this branch uses a lot of CPU and doesn't provide any
> feedback as to which hack is being built.

Thanks for the feedback. Yes, these dh_install scripts are quite resource intensive. They are more efficient when they are called once with a bunch of files and not serialised like now. You could add intermediate steps building up a list of files to install and then call dh_install once but it would add more code and I don't think build efficiency is very important. I don't think more verbosity is needed, because you will see which hack is being packaged if there is an error or warning.

> - For readability I'd list the hacks in split-hacks.conf like this:
> a) Don't know if the current script will handle comments like this
> b) This will make it harder to do a simple merge between Debian and Ubuntu but
> I think this is better than commenting on each one

a) The script will handle comments like this.
b) Yes, this would take us back to moving things around. I prefer having a static table where we just change a parameter. It is clearer for merges and for history. It is in alphabetic order, but you can just run sort -k2 if you want to _see_ them listed per package.

> It would be nice if you filled in a comment in split-hacks.config for those
> hacks that you move to *-extra in Ubuntu. For those hacks which are moved
> because of performance issues, a bug reference is most welcome.
>
> This will make it easier to evaluate these changes and possibly include them
> in Debian as well.

The choices I used for what stayed in the default packages were based on the comments by Alejandra Obregon in Bug #385850. I didn't want to get caught up in bike-shedding so I just went ahead with that list. The only comments made were positive factors about the hacks to keep. Though she did add that some of the ones moved were due to them being on your list of high-CPU usage ones. I could probably figure out which are which by cross referencing myself, but as she's on the canonical-ux team, perhaps she still has her notes and could share them with Robert?

>> b) This will make it harder to do a simple merge between Debian and Ubuntu but
>> I think this is better than commenting on each one
...
> b) Yes, this would take us back to moving things around. I prefer having a static
> table where we just change a parameter. It is clearer for merges and for history.
> It is in alphabetic order, but you can just run sort -k2 if you want to _see_
> them listed per package.

It seems to me that the main point of creating the script was to make doing a simple merge easier. So I deffer to the Debian maintainer... =)

> Currently building with this branch uses a lot of CPU and doesn't provide any
> feedback as to which hack is being built.

FYI, this has now been fixed in Debian git. We now generate the *.install files in split-config.sh and only call dh_install once afterwards. About 100 times faster :)