3:18 p.m.
Is anyone looking at this? The basic proposal is to create
/etc/kernel/preinst.d and /etc/kernel/postinst.d directories
and let external packages drop scripts in there that get called
on every kernel install.
3:26 p.m.
On Tue, 2007-08-14 at 16:18 -0400, Chuck Ebbert wrote:
Is anyone looking at this? The basic proposal is to create
/etc/kernel/preinst.d and /etc/kernel/postinst.d directories
and let external packages drop scripts in there that get called
on every kernel install.
The easiest place for it to not require lots of cruft in the kernel spec
file would be /sbin/new-kernel-pkg.
I'm not going to pass judgement on it being a good idea or not though :)
Jeremy
3:43 p.m.
Jeremy Katz wrote:
On Tue, 2007-08-14 at 16:18 -0400, Chuck Ebbert wrote:
> Is anyone looking at this?
Only insofar as asking for yours and davej's thoughts about doing it.
> The basic proposal is to create
> /etc/kernel/preinst.d and /etc/kernel/postinst.d directories
> and let external packages drop scripts in there that get called
> on every kernel install.
The easiest place for it to not require lots of cruft in the kernel spec
file would be /sbin/new-kernel-pkg.
Ooh, I like that.
I'm not going to pass judgement on it being a good idea or not
though :)
I will! I think it could be a Good Thing or at least a Useful Thing for
both kmod packages and dkms payloads. Of course, I also see the
potential for abuse here... Sketchy kmods or dkms payloads could
potentially wreak havoc on kernel installs if they cause a hang or failure.
I'd be happy to take a crack at implementation.
--
Jarod Wilson
jwilson(a)redhat.com
3:45 p.m.
Is there a reason to add a hack to the kernel %post in particular,
instead of just making people use rpm triggers? I mean, horror and all that.
But at least it's generic SEP horror, and not new hair for the kernel rpm
itself (i.e. our problem).
Thanks,
Roland
4:25 p.m.
Roland McGrath wrote:
Is there a reason to add a hack to the kernel %post in particular,
instead of just making people use rpm triggers? I mean, horror and all that.
But at least it's generic SEP horror, and not new hair for the kernel rpm
itself (i.e. our problem).
On the surface, I don't see why the couldn't. I suppose we should prod
Matt Domsch on why he's against using triggers for dkms, since his
objection in the bug doesn't list any details...
--
Jarod Wilson
jwilson(a)redhat.com
4:36 p.m.
On Tue, 2007-08-14 at 17:25 -0400, Jarod Wilson wrote:
Roland McGrath wrote:
> Is there a reason to add a hack to the kernel %post in particular,
> instead of just making people use rpm triggers? I mean, horror and all that.
> But at least it's generic SEP horror, and not new hair for the kernel rpm
> itself (i.e. our problem).
On the surface, I don't see why the couldn't. I suppose we should prod
Matt Domsch on why he's against using triggers for dkms, since his
objection in the bug doesn't list any details...
Triggers run at not exactly the time you expect them to. Which makes
them a little bit less helpful. Really, you want to plug-in after
depmod, etc are run but before the initrd is made. And you can't do
that from a trigger.
Also, triggers manage to cause all sorts of crazy fun weird corner
cases. Fear them. :-)
Jeremy
4:43 p.m.
Jeremy Katz wrote:
On Tue, 2007-08-14 at 17:25 -0400, Jarod Wilson wrote:
> Roland McGrath wrote:
>> Is there a reason to add a hack to the kernel %post in particular,
>> instead of just making people use rpm triggers? I mean, horror and all that.
>> But at least it's generic SEP horror, and not new hair for the kernel rpm
>> itself (i.e. our problem).
> On the surface, I don't see why the couldn't. I suppose we should prod
> Matt Domsch on why he's against using triggers for dkms, since his
> objection in the bug doesn't list any details...
Triggers run at not exactly the time you expect them to. Which makes
them a little bit less helpful. Really, you want to plug-in after
depmod, etc are run but before the initrd is made. And you can't do
that from a trigger.
Ew, yeah, okay, I could see that having odd side-effects in a few
cases... So what you're saying is we should do this in new-kernel-pkg?
;) At least that would make it mostly mkinitrd's problem and not the
kernel's...
Also, triggers manage to cause all sorts of crazy fun weird corner
cases. Fear them. :-)
/me cringes in terror... :)
--
Jarod Wilson
jwilson(a)redhat.com
6:06 p.m.
On Tue, 2007-08-14 at 17:43 -0400, Jarod Wilson wrote:
Jeremy Katz wrote:
> On Tue, 2007-08-14 at 17:25 -0400, Jarod Wilson wrote:
>> Roland McGrath wrote:
>>> Is there a reason to add a hack to the kernel %post in particular,
>>> instead of just making people use rpm triggers? I mean, horror and all
that.
>>> But at least it's generic SEP horror, and not new hair for the kernel
rpm
>>> itself (i.e. our problem).
>> On the surface, I don't see why the couldn't. I suppose we should prod
>> Matt Domsch on why he's against using triggers for dkms, since his
>> objection in the bug doesn't list any details...
>
> Triggers run at not exactly the time you expect them to. Which makes
> them a little bit less helpful. Really, you want to plug-in after
> depmod, etc are run but before the initrd is made. And you can't do
> that from a trigger.
Ew, yeah, okay, I could see that having odd side-effects in a few
cases... So what you're saying is we should do this in new-kernel-pkg?
;) At least that would make it mostly mkinitrd's problem and not the
kernel's...
When mdomsch, davej, jcm and I talked about it back in February, that
was the conclusion we reached. It should be pretty simple, too -- just
pick a directory[1], run things out of it that are executable.
Again, leaving out whether or not its a good idea ;-)
Jeremy
[1] Likely to be the most difficult part
9:39 p.m.
On Tue, 14 Aug 2007 19:06:23 -0400
Jeremy Katz <katzj(a)redhat.com> wrote:
When mdomsch, davej, jcm and I talked about it back in February, that
was the conclusion we reached. It should be pretty simple, too --
just pick a directory[1], run things out of it that are executable.
Again, leaving out whether or not its a good idea ;-)
I'd rather you comment about that as well. As I understand things,
this would make DKMS payloads much easier. There are some looking at
replacing kmods with that...
josh
midnight
On 15.08.2007 04:39, Josh Boyer wrote:
On Tue, 14 Aug 2007 19:06:23 -0400
Jeremy Katz <katzj(a)redhat.com> wrote:
> When mdomsch, davej, jcm and I talked about it back in February, that
> was the conclusion we reached. It should be pretty simple, too --
> just pick a directory[1], run things out of it that are executable.
>
> Again, leaving out whether or not its a good idea ;-)
I'd rather you comment about that as well. As I understand things,
this would make DKMS payloads much easier. There are some looking at
replacing kmods with that...
Well, I'd really like to see a combination of dkms and kmod's, so
ordinary users can get pre-compiled modules as kmods (or another
packaging standard for pre-compiled kernel-modules) and other can use
dkms if they want (or it could jump in in cases where the pre-compiled
packages are not yet available).
Just relying on dkms sounds crazy in my eyes.
BTW, the real solution for the bug which is mentioned in the subject of
this mail would be to dkms put the modules in a rpm that depends on the
kernel. Then it would be removed fine on kernel-uninstall.
CU
knurd
7:32 a.m.
On Wed, Aug 15, 2007 at 07:00:57AM +0200, Thorsten Leemhuis wrote:
Well, I'd really like to see a combination of dkms and kmod's, so
ordinary users can get pre-compiled modules as kmods (or another
packaging standard for pre-compiled kernel-modules) and other can use
dkms if they want (or it could jump in in cases where the pre-compiled
packages are not yet available).
Just relying on dkms sounds crazy in my eyes.
BTW, the real solution for the bug which is mentioned in the subject of
this mail would be to dkms put the modules in a rpm that depends on the
kernel. Then it would be removed fine on kernel-uninstall.
The modules built by dkms aren't included on a package because they
are built on demand on the user machine.
Or do you suggest that DKMS generate and install a RPM package when new
modules are compiled?
--
Eduardo
7:42 a.m.
On 15.08.2007 14:32, Eduardo Habkost wrote:
On Wed, Aug 15, 2007 at 07:00:57AM +0200, Thorsten Leemhuis wrote:
> Well, I'd really like to see a combination of dkms and kmod's, so
> ordinary users can get pre-compiled modules as kmods (or another
> packaging standard for pre-compiled kernel-modules) and other can use
> dkms if they want (or it could jump in in cases where the pre-compiled
> packages are not yet available).
>
> Just relying on dkms sounds crazy in my eyes.
>
> BTW, the real solution for the bug which is mentioned in the subject of
> this mail would be to dkms put the modules in a rpm that depends on the
> kernel. Then it would be removed fine on kernel-uninstall.
The modules built by dkms aren't included on a package because they
are built on demand on the user machine.
And that's bad ^w^w can be problematic for the same reasons why
installing CPAN-Modules or other Software without using rpm.
Or do you suggest that DKMS generate and install a RPM package when
new
modules are compiled?
The latter, which is possible afaik dkms.
BTW, I'm still interested in a kind of "kmod and dkms" merger, do have
both functionalities under one hood. But I still can't find a way to
make that work with maintaining only *one* spec-file/buildpath. I'd
appreciate it if someone could enlighten me if that's possible somehow.
CU
knurd
9:06 a.m.
On Tue, 2007-08-14 at 21:39 -0500, Josh Boyer wrote:
On Tue, 14 Aug 2007 19:06:23 -0400
Jeremy Katz <katzj(a)redhat.com> wrote:
> When mdomsch, davej, jcm and I talked about it back in February, that
> was the conclusion we reached. It should be pretty simple, too --
> just pick a directory[1], run things out of it that are executable.
>
> Again, leaving out whether or not its a good idea ;-)
I'd rather you comment about that as well. As I understand things,
this would make DKMS payloads much easier. There are some looking at
replacing kmods with that...
Yes, it makes doing things like dkms or even some of the kmodtool
horrors easier. And thus I suspect it's something of a necessary evil.
Doesn't mean I have to like it, though.
Jeremy
4:16 p.m.
On 08/14/2007 04:43 PM, Jarod Wilson wrote:
I will! I think it could be a Good Thing or at least a Useful Thing for
both kmod packages and dkms payloads. Of course, I also see the
potential for abuse here... Sketchy kmods or dkms payloads could
potentially wreak havoc on kernel installs if they cause a hang or failure.
That's what scares me about the whole idea.
6098
days inactive
6099
days old
kernel@lists.fedoraproject.org
13 comments
7 participants
participants (7)
-
Chuck Ebbert -
Eduardo Habkost -
Jarod Wilson -
Jeremy Katz -
Josh Boyer -
Roland McGrath -
Thorsten Leemhuis