On Tuesday 10 August 2004 21:47, Ian Murdock wrote:
> On Tue, 2004-08-10 at 15:29 -0500, Jeff Licquia wrote:
> > On Tue, 2004-08-10 at 08:11, Ian Murdock wrote:
> > > For now, I'm inclined to re-package gdm to add the pam_devperm.so line
> > > to /etc/pam.d/gdm and /etc/pam.d/gdm-autologin, and to add a "Depends"
> > > on libpam-devperm. The libpam-devperm defaults seem to be
> > > reasonable out of the box, so I don't think we need to repackage that.
> >
> > I'm not too enthusiastic about this, if only because all forks cause
> > maintenance headaches.
> >
> > We've got a few instances where little tweaks like this are necessary.
> > I'd like to investigate the possibility of adding them to anaconda in a
> > way that doesn't involve hacking them in.
>
> In this case, I'm not sure I see any other way to do it. If we do it in
> Anaconda, what happens when gdm upgrades? dpkg says, "I
> see you modified the configuration file /etc/pam.d/gdm. Should I
> keep your changes or install the package maintainer's new
> version?" In cases like that, I sometimes look at the diff,
> but in a lot of cases, I think, no, I never edited that file, so yeah,
> go ahead and give me the new version. And then sound suddenly
> stops working. Same problem as using something like cfengine to do it.
>
> At this point, I'd normally launch into my standard tirade that the
> Linux world needs a configuration management framework that separates
> configuration from packaging. But that's for another day. I think
> we have enough to tackle for now. And until we have such a thing, I
> think this is the only workable solution for situations such as this.
> It's a maintenance headache, but the support headache of dealing
> with user saying "my sound suddenly stopped working" are even larger.
OK. I started all this mess. Maybe I can draw things to a close :) I
downloaded the gdm source, and of course there are two simple file changes to
make that would fix it. But, that is not the point.
What is the consensus about what we should do?
As I see it, there are two mentioned solutions.
1. We hack the gdm package and just "update it" . This, as was pointed out,
causes headaches whenever gdm updates. We would have to update ours. Not a
big problem, but a minor one to add to all the other minor ones.. Also, not
sure if this would entail just bumping the version number, or renaming the
package to something like gdm-cl. I would guess just bumping up the version
number as that wouldn't interfere with other packages looking for the gdm
package.
2. As was suggested by Kalle, we can do a separate package that basically
adds the line to the appropriate files. As was noted early in the discussion
by Dario, scripting changes to files on the system might violate debian
policy. Also, as Ian talked about, whenever gdm updates the change will get
overwritten most likely by the unknowing user.
I can do option number one, and would tend to pull for that one, but option
number two would probably best be done by someone else. I am not that good a
coder..
Shall we take a vote on which of these or do something completely different?
Keith
|
