Hi Paul, Thanks for bringint this alltogheter! I'm new in contributing to Debian and I'm really thinking that this will be a big win!
Comments follows: 2012/7/10 Paul Tagliamonte <paul...@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. > > Please, don't forget this work in progress contributions: https://bitbucket.org/ronoaldo/desktop-theme-growing/src and https://bitbucket.org/uhansen/desktop-theme-elegance-blue/src. Obviously, there are tricky things done there to allow them to work on current theme setup, but some ideas are on the right track. > - 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 <paul...@debian.org> > : :' : Proud Debian Developer > `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 > `- http://people.debian.org/~paultag > Best Regards, -- Ronoaldo Pereira http://www.ronoaldo.net/
