Re: Some comments about the paper
On Tue, 28 Sep 2004, Miguel A. [ISO-8859-1] Arévalo wrote:
I'm not a debian-menu guru, but it seems that the cdd-menu stuff
rebuilds menus for every user, it would be better to have a set of
prebuilt menus for every role and make the menu-displaying app select
wich one to show.
Well, what if one user is member of two CDDs. I think just building
a user menu after a run of apt-get (not after each package installation)
is acceptable because it runs in background and no real problem. This
works with current tools and *every* "menu-displaying app". Else you
would have to change *every* window-manager etc. We are really
happy that most of them work with current debian menu system.
Of course until upstream has these config options there will be the
necesity for a work-around like this. But I think that this should be
"carefully pushed upstream". I'm sure, for example, that Novell will be
very glad to have them on GNOME 2.10 for ZenWorks 7.0 for Linux.
But there is also fvwm, GnuStep, ... (I guess we have about 50 menu
displaing applications).
But then again, take my comments on this with a grain of salt as
debian-menus are guru-magic at this point for me.
I'm no guru, but I guess we have a quite good solution if not focussed
only on Gnome + KDE.
This paragraph can be completely left out of the document. and
the /etc/group referal changed to the apropiate libc function call (I
hope you are not parsing /etc/group, I'm migrating to nss_ldap at this
moment ;-)
Does the code-snippet
for user in `getent group ${ROLE} ...`
answer your question?
And the point of having a new freeze dist.
This is not really new because we had this before we had package pools,
but it was dropped in favour of packages pools and now testing becomes
freeze for the time of freeze (while there is no testing at this time).
I do not really see the gain here (and as I said - just discuss this
with people on debian-devel).
This in fact is really interesting and could enhance the release cycle
as it currently is a little bit - but also not connected to CDD (while
interesting anyway - but you should discuss this on debian-devel because
most people who are doing release work do not read debian-custom).
I'm sorry, I'm not brave enough to post this to debian-devel.
Uhm, you do not need to be brave here. There are as kind people as
you might find here. The sheer number of people is larger and you might
tap on someones shoes - but there is no need to hide ideas.
At least this is the current situation. I personally have no problems
with this but there might be reasons to have some CDDs with a different
release cycle. If you think of schools (debian-edu) a yearly release
cycle (with releases in early summer) might make perfectly sense.
Yep, but I would always work on top of stable.
I would do this as well and there was a fine arguing in this thread
about what users *really* want. From personal experience in my
institute while we are migrating from NT to XP most of the people
say: "Why do I have to use this fucking different system which behaves
different from what I know. Give me back my old system."
Well, I think that if we have it on the wiki, as a starting point, but
this will give a great visibility to the project.
I can assure you for myself that I would definitely do not do anything
like editing a Wiki after having filed a bug report.
I'm pondering about starting a Corporate Debian CDD from the work done
on UserLinux ( :-S ) little by little on my free time.
Good luck
Andreas.
Reply to: