[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

"desktop-base" for wheezy+1

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.


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 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

Reply to: