Yves-Alexis Perez <email address hidden> writes:

> On mar., 2011-08-16 at 22:11 +0000, Andreas Rottmann wrote:
>> Yves-Alexis Perez <email address hidden> writes:
>> 
>> > But note that *preventing* people to chose what they're used to might
>> > not be the wisest.
>> >
>> Indeed.  I don't really care if I have to tweak configs to enable my
>> ~/.xsession script to be used, but with the Debian package, before this
>> issue had been fixed (assuming the .desktop file in question would have
>> been included as an example instead), I'd have had to:
>> 
>> # cp -a /usr/share/xsessions /etc
>> # cp /usr/share/doc/lightdm/examples/default.desktop /etc/xessions
>> # $EDITOR /etc/lightdm/lightdm.conf # to change the directory lightdm
>>                                     # looks for .desktop files in
>
> Why copy stuff in /etc? You only need to put a .desktop file
> in /usr/share/xsessions.
>
You are technically correct, but this is bad practice, much for the same
reason as editing any file under /usr (save /usr/local, of course) is;
quoting FHS 2.3, Footnote 23[0]:

[0] http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1450

  Software placed in / or /usr may be overwritten by system upgrades
  (though we recommend that distributions do not overwrite data in /etc
  under these circumstances). For this reason, local software must not
  be placed outside of /usr/local without good reason.

I thought not mucking around in the areas reserved for the package
manager was common sense, and hence the reason for the copying to /etc
would be obvious, but it seems I was mistaken.

>> Additionally, I would have had the burden to update my copy of the
>> desktop files in /etc/xessions, should they change in the package.
>> IMHO, for my usecase, that's quite more inconvinient than for some user
>> not caring about ~/.xsession just to ignore the corresponding dropdown
>> box entry.
>
> Again, not necessary, you can still use the ones from /u/s/xsessions.
>> 
See above.

>> > I don't really agree with the “confuse normal users in 99% of the
>> > case” (but again, it might depend which users we are considering).
>> >
>> If it's really decided, that for the Debian package, the default
>> Xsession should not be present in the menu, I'd at least expect
>> prominent documentation on how to enable this feature in
>> /usr/share/doc/lightdm/README.Debian (or somewhere similiar).  Of
>> course, *I* prefer having that feature enabled by default (and thanks
>> for the fix, BTW).
>
> For Debian package, it really depends on how the fix is done upstream,
> but I might keep shipping the lightdm-xsession.desktop file even then,
> because that's what Debian users are used to (at least that's what is
> done in GDM 2).
>
I'd highly appreciate that (along with some documentation).  In
addition, it would be really nice if lightdm (ideally upstream) provided
the capability of overriding (or extending) the .desktop files shipped
in /usr/share/xsessions with ones under the control of the system
administrator (instead of the package manager) in, say, /etc/xsessions.
I'm not sure how "hiding" menu entries could be facilitated, perhaps by
just creating an empty .desktop file in /etc/xessions, with the same
name as the one in /usr/share/xsessions.  With this feature it would be
both reasonably simple (and in conformance to good system adminstration
practice) to either enable .desktop files provided as an example (just a
simple copy, as you suggested), or conversely, disable any "confusing"
entries by running "touch /etc/xsessions/$CONFUSING.desktop".
I'm considering filing a wishlist bug requesting that feature...

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>