[Pkg-ltsp-devel] Bug#454478: ltspfsd should not recommends ldm

[vagrant at freegeek.org]

On Fri, Dec 07, 2007 at 10:18:54AM +0100, Oliver Grawert wrote:
> On Do, 2007-12-06 at 14:47 -0800, vagrant at freegeek.org wrote:
> > i'd be open to hearing more on the matter, particularly use cases where
> > the current layout doesn't work.
> you mean more like: ltspfsd is a no-op without the xprop set by ldm or
> that we install our rc scripts into /usr/share/ldm/rc.d ? 

i'm having trouble understanding you here (mostly because i think i
mis-read it at first)... what i think you mean is that ltspfsd should
continue to recommend ldm because ldm is the only thing that has
actually implemented hooks to make ltspfsd work?

ok, sure.

but i think soon there will be other things that also work with ltspfsd
that don't use ldm.  the very reason this bug report was filed is
because someone is exploring an alternative way to use ltspfsd without
LDM.  at that point, i think a suggests and/or enhances relationship is
more appropriate.

> or the fact that even if the udev scripts are harmless, making it
> possible to install them in a normal system which is more vulnerable to
> security leaks forces us to put more ressources into security ? 

i don't see any reason to be sloppy with security in any case.

> it think the recommends is totally justified here, at the current state
> ltspfsd wont work at all without ldm installed i'd even turn it into a
> dependency ... 

the request to lower it from recommends to a dependency clearly
indicates to me that there is interest in using ltspfsd without LDM.

the ltspfs/ldm interaction is not very complicated. 5 lines of patches
to sdm allow it to be used instead.

> the split would allow developers to develop their own solutions without
> the udev and ldm overhead installed using ltspfsd-core, 

> while i dont see a reason to enable normal users to install a
> non-functional ltspfsd package ...

the reason is that it would be trivial to implement the needed
functionality and there is expressed interest in doing so.

people have demonstrated and implemented systems using ltspfsd without
ldm.  i believe gadi at one point had actually used it as an automounter
to support local devices with rdesktop, if i remember correctly.

> note that in ubuntu ltspfsd even depends on ltsp-client to prevent the
> udev scripts being installed in normal systems 

yes, and ubuntu is much more focused on a single option for a single
purpose, which is excellent for defaults. 

i don't believe having a good default is a reason to make it more
difficult to implement alternatives, which making it a hard dependency
does. i do not want to see that in debian.

> (no matter if they are harmful or not, i just dont want them there
> since nobody ever tested how or if they interfere with existing rules
> and you can get unpredictable results)

this is the most convincing reason i have heard for the split- that the
udev rules *may* cause problems, though i have no indication that they
*do* cause problems.

if the udev rules are demonstrated to be probably or definitely harmful,
i see that as a valid reason for the split.

> imho the split is a good compromise for us all, i could keep the dep
> tree in place i want, you could install without the metapackage if you
> urgently want the scripts in normal workstations, mario could work with
> only the core package and users would not be able to break ther systems
> accidentially.

i see two possible packages:

 * ltspfsd-core, which contains the ltspfsd binary (maybe other scripts
that make sense to distribute with it)

 * ltspfsd, which contains the scripts, udev rules and such that are
currently in ltspfsd, minus whatever parts are moved to the ltspfsd-core
package. maybe keep the recommends on ldm.

i would rather keep a single package if at all possible- there are
already many thousands of packages in debian, and would only want to add
more if it really addressed problems or made the software more useful.

live well,
  vagrant