Proposal: build a unstable package that has all dependencies satisfied by stable. People using apt-pinning can install it in Woody. This package could run a bunch of scripts that set up the desktop on either stable or unstable box; for example, install ?XFree 4.2, KDE 3.0.4 and OpenOffice, set device permissions, themes, etc. If necessary, the script can branch based on whether stable or unstable is installed.
There is a compelling reason (for me, anyway) to use stable--I want to be able to recommend Debian to businesses, non-profits and other orgs, and I won't get very far down that path if I have to use something called "unstable."
Decoupling the install from the desktop setup seems like it should fit with the Debian Way ... and once the package (debian-desktop-kde, debian-desktop-gnome, debian-desktop-???) is all set it should be really easy to integrate it with any installer.
Mark, from what you write it sounds like sarge is never, ever going to be stable. I hope that won't be the case and I argue for working with sarge. It will save a lot of time and work IMHO. If you want to argue stable to organizations, you should, but not "stable + a lot of backports from unstable" since, well, that's not stable. --Sunnan
sarge is gonna be a far better experience for the average user: X4.2.1 for a start (plus auto mdetect, read-edid, discover etc), Gnome2/?KDE3. We could also start packaging pre-empt kernels which will help an awful lot for most desktops.
if we use PGI, we need to make sure that it works well. right now, it seems to be far from what it was on the progeny distrobution. it should have an expert configuration setting and needs to give th euser more input than what it currently does. most of the configuration is done out of the hands of the user and that leads to problems. I could not get the x-server up and runnig durring install becasue I could not manualy set it up, so I never got to the system configuration portion. I believe that if PGI fails to identify the GFX hardware, it should ask the user to manualy enter the information in a more debconf way. also, I believe that the desktop distrobution should have diffrent servers than stable or testing...that way, we can grab things from sid and get them out onto the desktop faster than the normal pace of standard debian. the reality is that most users who use debian on the desktop use sid. so if we grab stuff from sid, then fix it so it integrates into ?DebDesktop. oh yeah...we also need to include ALSA into the kernel, we need journaled FS, and in user space, we need all the alsa applications to replace the OSS packages, perhaps even hack some of the packages that do not work with alsa so that they will. this would give a great desktop experience.
I realy think that we need to move stuff along at our own pace where ever possable, then remerge our work into the main debian tree.
<b>2002/10/31 18:27 UTC (via web):</b>
What you're talking about here is basically a fork. This defeats the purpose of making this an internal project, and diminishes our ability to make use of important new developments in sid along with our own work (e.g. improvements to the installer, menu system, etc.) I don't think "time to market" is an issue here, as this is not a commercial product. Let's do it right. -- BenArmstrong
<b>2002/10/31 18:59 UTC (via web):</b>
What exactly makes it a fork? Using KDE 3.0.3? Not PGI. It's packaged with Woody. Releasing earlier will tackle the hard issues, like what is the menu structure and how we pick the ?BestOfBreedApps? -- MarkBucciarelli
<b>BenArmstrong, 2002/10/31 19:45 UTC (via web):</b>
I don't understand how you can "base it on Woody" and talk about "release" without involving a fork. You can't add anything to Woody (except for bug fixes for very severe problems or security issues). So what is it we're releasing if it isn't in sid? A fork, right? (Woody + DebianDesktop stuff.) Or do you mean we should build all packages against Woody and then upload them to sid? Even then, what will a release consist of? Do we duplicate the whole Debian release process for DebianDesktop, or invent our own release process? It just seems like there is extra work no matter how you slice it.
<b>MarkBucciarelli, 2002/11/01 01:16 UTC (via web):</b>
Here's what I think makes sense:
1. release a package in unstable called debian-desktop-kde.
2. this package has no dependencies that are not satisfied by stable
3. people use apt-pinning and then apt-get this package.
4. the package does a TON of stuff, like reconfiguring the menu, apt-getting other packages it requires, setting themes for a consistent UI, setting device permissions, and whatever else people think is required.
This would not be a fork and should work both for stable and unstable.
that is why we need to take from sid and have our own development path. we can take from sid, move along a testing and stable. the reason we need to not use main stable or testing is becasue we will have to make the apps look the same and mabye act the same in the future. as for the extra work...we are not here to make a simple installer...we are here to make debian a desktop system for normal users. that means graphical, automation through scripts, a consistent look to all apps no mater the tool kit, and good integration to the desktop. if you are a poweruser...use the main tree...if you need a stable server...use the main tree....if you want a nice desktop that has apps that look like they are part of a single product and have a faster release on newer applications, then pick us...we might not be 100% stable as the main tree, but we are stable enough to run a desktop system.
<b>2002/11/01 01:23 UTC (via web):</b>
hmmm...mark that seems like a nice idea..though I think we should have a gnome version as well. if we split the desktops so a person has to choose...then we could actualy keep gnome apps for the gnome desktop and kde apps for the kde desktop...that takes care of the look and feel of the entire system....though we should make a theme for mozilla so it will fit the respective desktop.
<b>2002/11/01 01:28 UTC (via web):</b>
hey mark...if we do somthing like that, we could get an option in the main installer to ask the user if it will be a desktop installation...then the installer can just pull our package and let it have at it. I think that is the best option
<b>MarkBucciarelli, 2002/11/01 15:34 UTC (via web):</b>
I've refactored the original statement at the top, taking out the bits about installation / PGI and fleshing out this debian-desktop-kde idea.
But hey, by basing it on woody you mean also including gnome1.4 instead of gnome2? I guess this isn't a viable way, we should have gnome2 definitely in. As it is targeted on a rather mainstream user, we should fulfill their call for bleeding edge desktop environments.. (say gnome2, anf of course ?KDE3)
<b>2002/11/05 01:23 UTC (via web):</b>
Sorry, don't know if there are Gnome 2 packages for Woody. I know you can install KDE 3 on Woody. So a Sid package would have to alter sources.list to point to the KDE 3 for Woody (and OpenOffice 1, and whatever else). Would this break policy? Anyway, I'm looking into Knoppix these days. It probably will be easier for me that going through the Debian process.
There are unofficial packages of Gnome2 for Woody, which are run extremely well. They are at http://people.debian.org/~kov/.
Sarge (or the next), please! Let's do this right. It's about making debian the best desktop distro, right? I think that should mean the released version of debian, not an apt-pinned hack.
<i>brought in from ?DebianDesktopProjectGoals</i>
<b>2002/10/31 18:21 UTC (via web):</b>
Basing -desktop on woody is not without additional cost. It means having to constantly backport to woody bits of the system that are being added to sid at the same time. It would be easier to get something working in sid first, and then as time/energy allow, do woody backports. -- BenArmstrong
2002/10/31 18:21 UTC (via web): Basing -desktop on woody is not without additional cost. It means having to constantly backport to woody bits of the system that are being added to sid at the same time. It would be easier to get something working in sid first, and then as time/energy allow, do woody backports. -- BenArmstrong
I would like to see debian desktop support APM or ACPI. This is just a wishlist because it seems like ACPI/APM support in Linux is pretty bad but it would be a good thing to implement when deemed ready. I wish I can totally replace windows 2000 which can suspend, resume, hibernate perfectly with linux but I can't. Right now I can leave windows 2000 on all day without feeling guilty but the same can't be said for linux.
I think one of the aims of a distribution that has a social contract is also to be socially responsible ie. use less energy.
MarkBucciarelli, 2002/11/01 15:56 UTC (via web): If Sid has this, it's one compelling reason to use Sid.
Makes an easy way to add third party hardware modules not included in the kernel
<i>Moved my diatribe on enviroments and packaging to NativeOrGeneric as it had become a bit off topic.</i>
I think Mark is thinking in the right direction. The debian-desktop-kde package or task follows with my ideas in the NativeOrGeneric discussion. For instance debian-desktop-kde could be a packages that depends on all the appropriate kde apps AND provides some standard debian themes for KDE. I have been thinking in the same direction regarding GNOME and ran into some interesting ideas.
However I think we should focus our efforts on Sid. There may be very large differences between Sarge and Woody when the time comes. When we upgrade to Sarge we have to do all kinds of work all over again. We should not duplicate our efforts. - MatthewMcGuire
What about a new set of icons, themes and windows decorations ? Something ala Debian. This could make KDE and Gnome more beautiful (others too, but these two are the WM that I use).
- These have been discussed in debian-devel and are being worked on by some. MatthewMcGuire
In regards to the icons, themes, etc. (art stuff basically) - any work that we do should be done with as much cooperation between us Debian Developers and the developers of the projects we are making art stuff for. It seems like the commercial distro companies employ their own artists to work on art for their distro alone (so it has a "redhat feel" or "?SuSE feel") instead of trying to improve the aesthetic state of Free Software in general, which we should do. Maybe if we work on art that looks good but isn't Debian specific, the we will reduce the amount of work that must be done in the future (by any/all of the distro developers).
9/4/2003 6:08 CDT
I think that although a fork or pinning would solve the WoodyOrSid problem, a better soultion would be to work on packages to get them moved into testing.
-- Matthew A. Nicholson
As far as I'm aware Gnome 2.2 (maybe 2.0) should be moving into Sarge by the time it's released. The move of 2.4 and later on, 2.6 into sid and then unstable should be faster than the addition of gnome 2 initially. Major updates in software such as the move from Gnome 1.4 to 2 and KDE 2 to 3 are a headache for all vendors as the dependency trees is redrawn and compatability is broken somewhat.
There really is no way around this for Debian, our stable/unstable setup is excellent for server software and we can't afford the resources needed for a Desktop branch. RedHat can ship a Gnome 2 fast because they have dedicated staff paid to hack on Gnome stuff and use Gnome as their primary desktop. Debian can't make this KDE vs Gnome choice, as argued above by others.
Ximian was quite slow in getting Gnome 2 out for a commercial company and it was a major haul getting Evolution ported to the new version of GTK and Gnome.
Our main efforts should not be on automatic scipts, we already have debconf, apt-get and dummy packages to take care of anything a script might do and we should stick with using packages in sources.list so people can update as normal rather than downloading them with scripts. We should however make sure that packages such as kde, gnome, gnome-core, and dekstop (which asks and informs about both) exist and work.
Concentrating on getting packages through the release and in seprate experimental style respositries so hackers can work on them is the way the trend is moving now and the way we should be working. Some of the biggest setbacks are different versions of libc and crucial system packages but aside from these there can be more of a view that desktop packages are important and the most recent possible should be made available to the distribution, e.g. steal some of fedoras configuration apps.
Sorry if this is a bit Gnome orientated. Although I admire and respect KDE I live entirely in Gnome world. - S. Tomlinson
I suggest another possible way to solve the stable/unstable dillema. Considering:
- Stable is quickly outdated for desktop systems.KDE, Gnome and other Desktop software are released typically once in 6 months.
- Unstable and, at some times, even Testing requires too much maintainance from the admin. (Even in Testing packages sometimes break when upgrading, i.e. due to changed config files)
Therefore I think it would be best too take the core of the system from Stable, and create rock-stable backports from Testing to Stable of Desktop software + the latest patch level of the kernel + mozilla + OpenOffice + maybe a few other things. This sound like a lot of work, but most of it is already being done:
- There are already backports of many of the projects I listed.
- The german government has created a Debian Woody based distribution, that shares of lot of the design goals of Debian Desktop, so they are probably willing to support Debian Desktop.
- Knoppix and Gnoppix are also based on Debian Woody, and come with recent version of KDE and Gnome.
In this way most work is already being done by others. Debian Desktop has to do some coordination, make a central mirror for the backports, and offer a slightly modified version of the Debian installer CD that adds a few lines to the sources.list.
-- Martijn Brouwer