[Pkg-ltsp-devel] sound and other feature support (was: current upload and bug status)

[Vagrant Cascadian]

On Wed, Aug 09, 2006 at 05:20:08PM +0200, Petter Reinholdtsen wrote:
> [Vagrant Cascadian]
> >    3) #356986: ltsp-server: ltsp should not be dependent on sound
> > 
> > i would like to move the ltsp-server dependency on "esound-clients"
> > to a recommends, and add it as a dependency on
> > ltsp-server-standalone. it's not truely necessary to have sound on
> > the clients, even if it may be the default.
> 
> To me, this is a question of how many steps should be required to
> enable sound support.  At the moment, it is a single switch in
> lts.conf, and it isn't enabled by default.  I believe that is how it
> should be, perhaps with some extra code to detect if sound hardware is
> available and enable it automatically if it is.

sure.

> The bug reporter on the other hand seem to take the approach that
> everything that isn't strictly and technically required to get ltsp
> running should not be listed as a dependency. 

i agree with that philosophy... i think it should be possible to get a
bare-bones install without cruft, if you know what you're doing. as long
as the defaults are for a more complete system, this shouldn't be a
problem...

> I believe that approach
> is doing our users a dis-service.  The only advantage is saving a few
> bytes in the chroot and on the ltsp server, and I believe that
> advantage is minor compared to the extra support load generated by
> trying to explain to a school sysadmin that he first need to install
> some packages on the server, then in the client chroot, and then
> enable sound support in lts.conf and hope he didn't run into any
> problems with broken apt sources, broken CDs, inaccesible networks
> etc.

i think we can get the best of both possibilities by re-thinking the
packages a little:

what if, instead of having "ltsp-server" and "ltsp-server-standalone",
we switched the dependencies such that "ltsp-server" pulls in
everything(sound, X, ssh-server, dhcp server?), and there was an
"ltsp-server-minimal" which only had the absolute necessities
(ltsp-build-client, ltsp-update-kernels?).

this would make the defaults inclusive and easy for the more complete
installations, while it would still be possible to satisfy the people
who need a more basic installation. it's a little tricky in that the
dhcp server should be optional, as many networks already have a dhcp
server and this could interfere with that.  so maybe that should still
be separate.

same thing could be done for "ltsp-client" package, with an
"ltsp-client-minimal" package that gets the bare functionality.

i even talked a little with ogra and otavio about splitting it up a
little more and have ltsp-server-sound/ltsp-client-sound,
ltsp-server-x/ltsp-client-x, ltsp-server-dhcp, etc. there could be a
danger of too many packages that do too little, so we'd have to be smart
about that, but it's probably worth it for the most common
functionality.

the ltsp-build-client plugins system is great for that, and we should
move more scripts to a similar system...

> Would you be able to guide your grandmother through this procedure on
> the phone?  If yes, you can try with mine as well, and see if the
> procedure is simple enough or not.  I would not be able to do that.

well, i honestly think i'd hit those barriers well before the dependency
on sound systems :P

> Enabling sound in LTSP must be very simple to avoid lots of support
> calls to the people supporting the system.  A script do go through the
> steps could be created, but there are still all the external forces
> affecting the success rate of that script. :/

i agree, the defaults need to make everything easy. i think we can make
that possible without making it impossible to have a barebones system
(without manually hacking the install scripts).

live well,
  vagrant