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). 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 :) 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. 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'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. 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. 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 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. 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. 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
Attachment:
signature.asc
Description: Digital signature