Re: Rename desktop-base ?
On 4/14/07, Matthew McGuire <firstname.lastname@example.org> wrote:
I renamed the subject to clean out the reference. I have no idea why
kfreebsd was mentioned in the original email.
Simple because I would like to use Debian GNU/Linux or Debian
GNU/kFreeBSD Lenny Desktop. :)
If the debian desktop packages are going to reorganized for Lenny, then
it would suit to make a list of the debian-desktop package goals first.
So far there is a general wish for splitting the packages by purpose. I
agree with this and think it would make maintaining the packages
simpler. However it will be very important to limit the dependencies to
prevent complex dependency chains from happening. Here are some ideas on
the packages that could be used. This is derived from emails on the list
and anything that comes to mind at 3am EDT. :-)
Considering that I'm the maintainer and that the split was also
discussed with Daniel Holbach that also does artwork related
packaging, I felt free to post only a summary and didn't go down to
the further details.
This package is responsible for providing base infrastructure and
configuration mechanisms used by the debian-desktop package suite. To
that effect I feel that we should define and maintain the file system
structure for any shared elements in this package. In effect this makes
desktop-base the central package for directing and defining desktop
package policy and conformance. All debian desktop packages should
depend on this package in order to help maintain consistency.
uh, no? desktop-base was just our safe net to implement common debian
desktop artwork for Etch. It can (and probably will) be only a
transitional package in the near future.
This would clearly be a package that provides desktop artwork for themes
and other forms of visual improvements. This isn't just for the eye
candy people. This is equally important for visually impaired users or
users that need other forms of custom visual requirements. Initially I
am considering themes and artwork for the visually impaired but it might
be feasible to support screen readers and other accessibility features.
However that might be better suited for a package like
desktop-accessibility or similar.
debian-desktop-artwork will contain GNOME, KDE and Xfce updated
debian-moreblue themes and room for custom Debian Distributions add
their own stuff, pretty much what we've into desktop-base now.
This would provide a collection of scripts the user may optionally use
for situations like auto mounting local drives and partitions. It might
also be good to include default scripts for creating basic backups and
other useful tasks that people need. Each script would need to be
disabled by default and enabled using debconf to support preseeding.
The regular Debian Desktop user shouldn't need to open a terminal to
make backups, but actually he can do it without a script. I agree with
the auto mounting stuff and I would prefer call this
I think adding the prefix debian- to these package name is a good idea.
Although the debian- prefix may seem unnecessary it makes creating
things like ubuntu-desktop-base and distroX-desktop-base  much
simpler. Not that I want this to happen, but it can't be prevented. So
why not prepare for it now? Ideally the desktop-base package
specification could be used to apply default branding and configuration
for a derivative distribution using the alternative distroX-desktop-base
package. This brings to mind the possibility of using alternatives for
this sort of thing as well, but that seems overreaching at this stage.
This idea could definitely use Conflicts: to prevent multiple copies of
the desktop-base to be installed. Imagine being able to change the
branding using a simple:
apt-get install distroX-desktop-base distroX-desktop-art
derivative is something we don't need to support, but custom debian
distributions yes. Actually distroX-desktop-base is a reality with the
alternatives we've in place for desktop-base, did you see?
I don't think splitting desktop-art into GNOME, KDE, XFCE versions is
necessary or even a good idea. It will make it more difficult to
synchronize the art and c\would require duplicate copies of the art
used. Then again I might have missed something on this point.
No, we won't split it (again) and miss the first point that guided us
to reunite here during Etch development cycle.
Now the big bugaboo... Localization.
The current packages don't support localization and don't really need
them now. However if we start setting up common scripts and provide
desktop interfaces to them with something like say zenity or kdialog
then it stands to reason that we will also need these to be localized in
the future. It also makes sense to provide a localization solution for
the distroX issue mentioned above. I dunno, maybe this is also a bit
overreaching at this stage as well.
Believe in me, it really is. I also work on a mainly pt_BR CDD and the
current desktop-base approach doesn't fail on this camp. The point of
renaming is that add utils and artwork in a package called 'base' is
confusing, what isn't base then?