On Wed, Jul 11, 2012 at 10:06:02AM +0200, Josselin Mouette wrote: > Le mardi 10 juillet 2012 à 22:04 -0400, Paul Tagliamonte a écrit : > > - 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). > > While the later part (one package per theme) is a good idea, I think > that splitting the plymouth, gdm, kdm etc. stuff is wrong. You’re bound > to end up with stupid dependencies. > > For example, if theme-defaults depends on (or recommends) Whoh, right here. There's only src:theme-defaults, not binary -- there will be no cenetral package in my brave new world. If you need the GDM stuff, use the GDM metapackage, if you need the KDE stuff, use the KDE metapackage. > theme-default-gdm? And will theme-default-gdm depend on gdm? If you’re > missing the former, your metapackage is useless, and if you’re missing > the latter, the split is useless. If you add both, you will end up Yah, sure, but there's no central package. This is to deal with dragging in more deps then we should for something that's not installed (but could be). > installing gazillions of stuff as soon as theme-default is here. > > I find it much better to simply ship every theme in a single package > that holds a theme for all supported stuff. Especially given that some > pieces of the theme might be shared between several components. I'll deal with this question down below :) > > > 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. > > Yeah, don’t put the cart before the horse. > > > 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. > > Why the complexity? Having "swapable" themes is important. If someone wants to stay at moreblue, they shouldn't have to pin a krufty version of the defaults package -- they should be able to just apt-get install the theme they prefer. If we don't use virtual packages, we would end up breaking the default package, which may be being depended on (see the "Re: Recommends for metapackages" flamewar going on now in debian-devel about saying just use Recommends ;) ) > > > Package: task-desktop > > Depends: gnome, theme-default-gnome | theme-gnome > > Package: gdm3 > > Recommends: theme-default-gdm | theme-gdm > > Package: theme-default-gdm > > Provides: theme-gdm > > Package: theme-foo-gdm > > Provides: theme-gdm > > Package: theme-bar-gdm > > Provides: theme-gdm > > Why why why? > Why when you can simply have one theme-joy package that provides > everything needed? > > Please don’t make things more complex just for the sake of having more > work to do. The idea here is to prevent the theoretical problem embodied in bugs 613040, 625222 and 680583. (respectively two plymouth depends issues that can only be resolved as depending on the correct plymouth tools, which would require plymouth on all desktop-base installs, and the librsvg bug, where we're bringing this in on KDE installs, even though we don't need it) The idea isn't to maintain compatibility with desktop-base as is, but solve the general problem. Sure it's more work, but it's needed to let dpkg behave as it should. > > > 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) > > Bullshit. I agree that JPGs should be banned, but PNG files *are* their > own source even when the original format is lost. I'm going to use some handwaving here and say we can debate what exactly is DFSG free later. To put some wood on the fire, I think the debian-games team might have some hash words for this, since it gives upstream an incentive to "lose" the original -- and such behavior has been spotted in the wild. > > Although anyway, SVGs are much better to handle multiple resolutions. > But this is a technical reason, not a licensing one. I agree with this point for the reasons you give, but also argue it's a better legal solution as well. > > -- > .''`. Josselin Mouette > : :' : > `. `' > `- > > > -- > To UNSUBSCRIBE, email to debian-desktop-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > Archive: [🔎] 1341993962.10559.46.camel@pi0307572">http://lists.debian.org/[🔎] 1341993962.10559.46.camel@pi0307572 > Cheers, 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