2012/7/10 Paul Tagliamonte
<paultag@debian.org>
Howdy, y'all,
Now that we've gone and (for the most part) got wheezy into a shape that's
generally fit for release (granted we have a few things to shine up, etc, but
the majority of the work is done), I'd like to talk a bit about the plans
for wheezy+1.
My general plan (please debate)
===============================
- Replace desktop-base with a theme-defaults package, which will act as a
stable set of binary metapackages to recommend (or depend on). Rather then
a single (monolitic) theme package, this will create a "fragmented" set,
stuff like "theme-default-gdm" "theme-default-plymouth" or
"theme-default-kdm". There's currently an issue with us not dragging in the
correct deps because depending (or recommending it) will result in all
installs having something that's not really needed in all cases. More on
this below. As part of this, we'd have to introduce a few virtual packages
to provide (again, more on that later).
Great! This would allow a very small install and setup and avoid unecessary code on package install.
The technical implementation of this is a bit more complex and not totally
thought out, but I plan on spending some of my weekend testing the ideas
that I'm floating around.
- Package themes as "first-class" packages. That is to say, we'll introduce
"theme-debian-joy", "theme-debian-spacefun" and "theme-debian-moreblue" to
start. Each of these will follow the fragmented setup. I suggest creating
a packaging team for technical discussions of theme packaging, as well as
a list of interested sponsors.
Hopefully this can also act as the theme maintainer with the interested
parties listed as co-maintainers. This will let us ensure we can make
team-uploads to keep everything fresh, and track bugs together.
Remember, teamwork makes the dream work.
- Vote for a default theme (in a binding way) 2 months before freeze. This may
consist of a list-wide vote, or perhaps a committee (at our dear DPL's
discretion) of both primarily technical and primarily artistic folks. This
way we can pick a theme that not only looks good, but is practical to
implement in the timeframe given. The big changes to the theme shall be done
with ample time before the freeze (a week at minimum) to ward off potential
bugs. The idea here is to get the theme into the archive *before* a vote :)
Perfect! There should definitelly be something to make rulles clear to everyone involved: both artists, users and the Debian developers who bring the OS to life. Making packaging easy for both artists and developers is a key to achieve that, IMHO.
Implementation Details
======================
OK. Here's some more information on what (exactly) I'm thinking.
theme-defaults
--------------
The name is bad, so we need a better name.
My suggestions:
desktop-theme-base
desktop-theme-common
theme-common
I'd like to keep "debian" out of the
name, since this would allow derivatives to update the theme locally (e.g.
upload theme-defaults/7.0distrib1), or just plain blacklist theme-defaults
and re-upload out-of-sync. This would make everyone's life much (much) easier.
The way we deal with themes is also very important. To make this go over like
butter, perhaps we should establish a themes policy. After we get the method
down, I'd be happy to document and refine said policy.
I agree that should be a theme policy. Policy is aways good to make everybody work in the same direction, and the changes you suggest really should get into the Debian Policy and manuals. I offer myself to help reviewing if you need!
I'm thinking we'd add themes to a central path (or a sane path, like the
default wallpaper path, etc, etc) and use some handwaving, glitter and magic
to swap them into canonical locations which packages use (perhaps
update-alternatives and some wrappers? something like vim-addons(1)?),
as well as some lintian checks to make sure no one futzs with dropping themes
on the system out of policy or anything like that.
Amazing. Would it make sense to have a "Default" theme, provided by the theme packages itself.
Theme packaging
---------------
We should look at creating a dh-themes package with some helper routines for
theme work. I think we should figure out exactly where we need help before
we go off hacking on some crazy routines. After all, some dh_install might be
all we need.
I see a few tooling needed, like a few scripts to transform a source artwork (svg, xcf) into proper imagery (png, animations?) and create the proper resolutions and formats. I like the dh_* style, and maybe some cdbs rule/class to make things very easy when packaging. I really like avoiding boilerplate code.
We should also create a theme-hello package to let people base their work on,
anyway. Eventually, generating a new theme should be a snap (and fairly
easy to do)
Virtual Packages
----------------
We might also need a few virtual packages - we would need to set up
a package like theme-default-gdm to depend on theme-gdm (or so), and recommend
something like "theme-debian-joy-gdm". This way, if some user installs
theme-debian-moreblue-gdm, they will be able to remove theme-debian-joy-gdm
without trouble.
pabs had the idea of using them as follows:
Source: tasksel
Package: task-desktop
Depends: gnome, theme-default-gnome | theme-gnome
Source: gdm3
Package: gdm3
Recommends: theme-default-gdm | theme-gdm
Source: theme-meta
Package: theme-default-gdm
Provides: theme-gdm
Source: theme-foo
Package: theme-foo-gdm
Provides: theme-gdm
Source: theme-bar
Package: theme-bar-gdm
Provides: theme-gdm
While I think it's a pretty great setup, having so many copied Recommends, I'd
tend to something like:
Source: gdm3
Package: gdm3
Recommends: theme-default-gdm
Source: theme-meta
Package: theme-default-gdm
Depends: theme-gdm
Recommends: theme-foo-gdm
Source: theme-foo
Package: theme-foo-gdm
Provides: theme-gdm
Source: theme-bar
Package: theme-bar-gdm
Provides: theme-gdm
I like more the second style. Does dpkg/apt likes more one of them when, say, upgrades or updates happen? Wich one is more d-i friendly?
We would need to flesh out a list of new virtual packages and propose it to
debian-devel for consensus making. I don't think we need to focus too much
on this *just* yet, but feedback here would rock.
License Concerns
================
We *must* ensure we have *all* sources, for *all* themes in debian/main. We
*must* adhear to very strictly to the DFSG. We *must* define exactly what
this means, well in advance.
That means lots of SVGs, XCFs etc. I suggest we be very careful about including
.jpg or .png files (etc) without their sources (except photos, etc that are
actually in jpg / pngs)
Anyway, best judgement, but we must be strict on this.
All the files must also be buildable with the packages from debian/main.
+1 for that
OK, so what does this all mean?
===============================
I know I'm suggesting a lot of drastic changes, and I know this is all a big
exercise in policy-paperwork, but it could introduce some very huge technical
wins for themes - as well as (officially) supporting switching themes with
simple apt-get usage.
Keep in mind *none* of this is solidly planned. This is just an idea for how
we *might* move for wheezy+1.
I'll be glad to help on packaging, testing, reviewing or whenever is needed.
Ready, go!
Paul
--
.''`. Paul Tagliamonte <paultag@debian.org>
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`- http://people.debian.org/~paultag