Bug#498395: gdm doesn't really depend on gksu

Loïc Minier lool at dooz.org
Fri Sep 12 12:40:52 UTC 2008


On Wed, Sep 10, 2008, Anthony DeRobertis wrote:
> >  gdmsetup is a significant amount of functionality which we directly
> >  want to support; if gdmsetup doesn't work, the package has a RC bug.
> >  This includes users who don't have gksu and try to launch gdmsetup.
> 
> That's different than how I read that section. I read it as requiring a
> depends if without that dependency, the package provides no significant
> functionality; if I understand correctly, you read it as requiring a
> depends if without the package loses any of its significant functions. I
> believe my reading is more correct (especially considering Recommends),
> but I suspect you believe the same of your reading.

 To be honest, I asserted the above to hint that your reading of policy
 might not be 100% correct.  The truth is quite certainly in between:
 the maintainers decide what is the important amount of functionality a
 package provides, and use depends to ensure this functionality works.

> >  Please explain what you are really trying to achieve instead of
> >  negociating individual dependencies by throwing policy quotes at us.
> Well - two things. First, I confess I've gotten a little annoyed at
> dependencies which make me install programs which I don't need: I
> maintain some machines with small (by today's standards) amounts of disk
> space. Granted, its not much space in this case.

 Yup, I actually checked the size of gksu and libgksu first to see
 whether we were speaking of a big dep tree; that's why I was a bit
 annoyed by the request to begin with and suspected it had something to
 do with suid binaries on the system which you wouldn't want, or along
 these lines.

> Second, and more important in this case, is I'm trying to uninstall
> gnome-keyring, which gksu depends on (though, I guess, I could have
> filed this bug there, too). I'm trying to uninstall gnome-keyring
> because otherwise gnome-session starts it up, and sets the SSH_AUTH_SOCK
> environment variable to use it instead of ssh-agent (even though
> SSH_AUTH_SOCK was already set). I could not find a way to make
> gnome-session not do that, and don't use gnome-keyring anyway, so I just
> tried to uninstall it.

 This bug annoyed me and annoys other users; I reported it upstream.
 There are two ways to workaround it:
 a) easy way and the one I use: wet
    /apps/gnome-keyring/daemon-components/ssh to false and gnome-keyring
    stops loading its ssh agent
 b) upstream way (what upstream told us when I forwarded my complaints)
    is to build gnome-keyring without ssh support; not an option if you
    actually want to use gnome-keyring as a ssh agent

 The real fix would be not to start the ssh component if SSH_AUTH_SOCK
 is set, but upstream doesn't want to because if ssh is set to true, it
 means the ssh component shall be started unconditionally.

 Check GNOME <http://bugzilla.gnome.org/show_bug.cgi?id=519486> which
 has links to the Debian bug.

 I'm not happy with the current Debian resolution, but don't have the
 time to cook up a patch.

> I want to use ssh-agent instead of gnome-keyring-daemon

 (I use it)

> >  (Also, I recommend you to Cc: <pkg>@packages.debian.org or the bug as
> >  getting your message from the bot's transcript isn't too nice for other
> >  maintainers)
> Sorry about that; I had assumed debbugs would forward that message along
> to the maintainers.

 Nope, only the transcript.


 Also FYI, the messages you addressed to me directly only reached me
 today; blocked for long before reaching my mail server for some reason.
 I've configured my server to do sender callouts, hope that's not the
 issue.

-- 
Loïc Minier





More information about the pkg-gnome-maintainers mailing list