Re: Disable CONFIG_ACPI_SYSFS_POWER?
On Feb 18, 2008 6:06 AM, Dave Jones <[EMAIL PROTECTED]> wrote: > > On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: > > On 02/16/2008 06:53 AM, drago01 wrote: > > > Hi, > > > I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build > > > directly) on my laptop. > > > Hal detects two batteries because it looks in sysfs and in procfs for > > > the battery info. I tryed to apply the patch from the hal-list which > > > causes hal to not look in procfs but in sysfs only when the sysfs info > > > is available. The problem with this is that the info in sysfs is broken > > > (capcity 3.0 Wh etc while the procfs info is correct 45Wh). > > > I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs > > > info already provides this data for userspace and does not report broken > > > values. > > > > > > > We should be enabling either one or the other, not both. > > > > For Fedora 9 maybe it should be the sysfs interface if it works. > > > > For 8 it should be only procfs to be backwards compatible. I'll do that. > > Yeah, you need a new enough hal aparently, which I guess f8 didn't have. > F9 should be safe to be using just the sysfs stuff. I have not tested rawhide on a laptop yet, but it seems that rawhide still uses hal-0.5.10 (which is also the lastest upstream); on F8 this one was not working for me. But David might know more ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Disable CONFIG_ACPI_SYSFS_POWER?
On Mon, 2008-02-18 at 11:23 +0100, drago01 wrote: > > Yeah, you need a new enough hal aparently, which I guess f8 didn't have. > > F9 should be safe to be using just the sysfs stuff. > > I have not tested rawhide on a laptop yet, but it seems that rawhide > still uses hal-0.5.10 (which is also the lastest upstream); on F8 this > one was not working for me. > But David might know more The fixes should be in git (maybe, when I checked a few months ago some bits were missing from sysfs); I'll test and put a newer snapshot in later this week. David ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote: > is there any reason why we can't just move %post to %posttrans? %posttrans breaks the way we do bootloader config updating as it leaves around no entries in the bootloader config after all the %preuns have been processed. I looked at this a few months ago and thought we talked about it here, but it might have just been mail between davej and myself Jeremy ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, Feb 18, 2008 at 09:36:49AM -0500, Jeremy Katz wrote:
> On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote:
> > is there any reason why we can't just move %post to %posttrans?
>
> %posttrans breaks the way we do bootloader config updating as it leaves
> around no entries in the bootloader config after all the %preuns have
> been processed. I looked at this a few months ago and thought we talked
> about it here, but it might have just been mail between davej and myself
ok, new-kernel-pkg grows a --rpmposttrans mode then to call these
hooks, and we add a %posttrans to each kernel RPM.
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
--- kernel.spec.orig2008-02-15 21:06:33.0 -0600
+++ kernel.spec 2008-02-18 09:12:02.0 -0600
@@ -1590,12 +1590,23 @@ fi\
%{nil}
#
+# This macro defines a %%posttrans script for a kernel package.
+# %%kernel_variant_posttrans [-v ] [-s -r ]
+# More text can follow to go at the end of this variant's %%post.
+#
+%define kernel_variant_posttrans(s:r:v:) \
+%{expand:%%posttrans %{?-v*}}\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*} || exit $?\
+%{nil}
+
+#
# This macro defines a %%post script for a kernel package and its devel
package.
# %%kernel_variant_post [-v ] [-s -r ]
# More text can follow to go at the end of this variant's %%post.
#
%define kernel_variant_post(s:r:v:) \
%{expand:%%kernel_devel_post %{?-v*}}\
+%{expand:%%kernel_variant_posttrans %{?-v*}}\
%{expand:%%post %{?-v*}}\
%{-s:\
if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\
--- new-kernel-pkg.orig 2008-02-15 13:22:46.0 -0600
+++ new-kernel-pkg 2008-02-18 09:04:44.0 -0600
@@ -96,7 +96,7 @@ usage() {
echo " [--kernel-args=] [--remove-args=]" >&2
echo " [--banner=] [--multiboot=multiboot]" >&2
echo " [--mbargs=mbargs] [--make-default]" >&2
-echo " <--install | --remove | --update> " >&2
+echo " <--install | --remove | --update | --rpmposttrans>
" >&2
echo " (ex: `basename $0` --mkinitrd --depmod --install 2.4.7-2)" >&2
exit 1
}
@@ -185,6 +185,19 @@ install() {
}
+rpmposttrans()
+{
+local d
+local f
+for d in /etc/kernel/postinst.d /etc/kernel/postinst.d/$version ; do
+ if [ -d $d ]; then
+ for f in $(ls $d/); do
+ [ -x $d/$f ] && $d/$f $version
$bootPrefix/$kernelName-$version
+ done
+ fi
+done
+}
+
remove() {
# FIXME: is this a good heuristic to find out if we're on iSeries?
if [ -d /proc/iSeries ]; then
@@ -193,6 +206,16 @@ remove() {
return
fi
+local d
+local f
+for d in /etc/kernel/prerm.d /etc/kernel/prerm.d/$version ; do
+ if [ -d $d ]; then
+ for f in $(ls $d/); do
+ [ -x $d/$f ] && $d/$f $version
$bootPrefix/$kernelName-$version
+ done
+ fi
+done
+
if [ -n "$cfgGrub" ]; then
[ -n "$verbose" ] && echo "removing $version from $grubConfig"
$grubby --remove-kernel=$bootPrefix/$kernelName-$version
@@ -379,7 +402,7 @@ while [ $# -gt 0 ]; do
done
# make sure the mode is valid
-if [ "$mode" != "--install" -a "$mode" != "--remove" -a "$mode" != "--update"
] ; then
+if [ "$mode" != "--install" -a "$mode" != "--remove" -a "$mode" != "--update"
-a "$mode" != "--rpmposttrans" ] ; then
usage
fi
@@ -451,6 +474,8 @@ elif [ "$mode" == "--remove" ]; then
remove
elif [ "$mode" == "--update" ]; then
update
+elif [ "$mode" == "--rpmposttrans" ]; then
+rpmposttrans
fi
exit 0
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, Feb 18, 2008 at 09:49:44AM -0600, Matt Domsch wrote:
> On Mon, Feb 18, 2008 at 09:36:49AM -0500, Jeremy Katz wrote:
> > On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote:
> > > is there any reason why we can't just move %post to %posttrans?
> >
> > %posttrans breaks the way we do bootloader config updating as it leaves
> > around no entries in the bootloader config after all the %preuns have
> > been processed. I looked at this a few months ago and thought we talked
> > about it here, but it might have just been mail between davej and myself
>
> ok, new-kernel-pkg grows a --rpmposttrans mode then to call these
> hooks, and we add a %posttrans to each kernel RPM.
and we need /sbin/installkernel to call it too. That's not called
from within an RPM, but is called when the user manally builds a
kernel.org kernel.
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
--- installkernel.orig 2008-02-18 09:58:14.0 -0600
+++ installkernel 2008-02-18 09:58:42.0 -0600
@@ -79,4 +79,5 @@ ln -fs ${RELATIVE_PATH}$INSTALL_PATH/Sys
if [ -n "$cfgLoader" -a -x /sbin/new-kernel-pkg ]; then
/sbin/new-kernel-pkg --mkinitrd --depmod --install $KERNEL_VERSION
+ /sbin/new-kernel-pkg --rpmposttrans $KERNEL_VERSION
fi
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Disable CONFIG_ACPI_SYSFS_POWER?
On Mon, Feb 18, 2008 at 11:25:40AM -0500, Kyle McMartin wrote: > On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: > > On 02/16/2008 06:53 AM, drago01 wrote: > > > Hi, > > > I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build > > > directly) on my laptop. > > > Hal detects two batteries because it looks in sysfs and in procfs for > > > the battery info. I tryed to apply the patch from the hal-list which > > > causes hal to not look in procfs but in sysfs only when the sysfs info > > > is available. The problem with this is that the info in sysfs is broken > > > (capcity 3.0 Wh etc while the procfs info is correct 45Wh). > > > I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs > > > info already provides this data for userspace and does not report broken > > > values. > > > > > > > We should be enabling either one or the other, not both. > > > > my logic was people could be running rawhide kernels on old userspace > (i do this, for instance.) actually that's a really good point, given how bad rawhide has been lately at being installable. I do the same thing btw (f9 kernel on f8) because of this, and hadn't picked up on this breakage because my laptop runs f8 kernel. > > For Fedora 9 maybe it should be the sysfs interface if it works. > i don't really see a harm in having both. I imagine that eventually someone upstream will make the decision a no-brainer by removing the proc stuff. Not shipping it does mean that nothing new will start depending on it. (Unlikely I know, but still...) > > For 8 it should be only procfs to be backwards compatible. I'll do that. > agreed, don't want to tempt fate on f8... ACK. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Disable CONFIG_ACPI_SYSFS_POWER?
On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote: > On 02/16/2008 06:53 AM, drago01 wrote: > > Hi, > > I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build > > directly) on my laptop. > > Hal detects two batteries because it looks in sysfs and in procfs for > > the battery info. I tryed to apply the patch from the hal-list which > > causes hal to not look in procfs but in sysfs only when the sysfs info > > is available. The problem with this is that the info in sysfs is broken > > (capcity 3.0 Wh etc while the procfs info is correct 45Wh). > > I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs > > info already provides this data for userspace and does not report broken > > values. > > > > We should be enabling either one or the other, not both. > my logic was people could be running rawhide kernels on old userspace (i do this, for instance.) > For Fedora 9 maybe it should be the sysfs interface if it works. > i don't really see a harm in having both. > For 8 it should be only procfs to be backwards compatible. I'll do that. > agreed, don't want to tempt fate on f8... cheers, kyle > ___ > Fedora-kernel-list mailing list > Fedora-kernel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Disable CONFIG_ACPI_SYSFS_POWER?
On Mon, Feb 18, 2008 at 11:48:20AM -0500, Dave Jones wrote: > > > For Fedora 9 maybe it should be the sysfs interface if it works. > > i don't really see a harm in having both. > > I imagine that eventually someone upstream will make the decision a no-brainer > by removing the proc stuff. Not shipping it does mean that nothing new will > start depending on it. (Unlikely I know, but still...) > This is true. The patch I submitted to hal (I think it's in git, but not sure it has made it into a release or Fedora) preferentially selects sysfs over procfs, so hopefully that will at least encourage people to fix the shortcomings, if any, in the sysfs interfaces. :/ cheers, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
Matt Domsch ([EMAIL PROTECTED]) said: > https://bugzilla.redhat.com/show_bug.cgi?id=433121 > > DKMS would like to have the opportunity to run it's > auto-rebuilder/installer after a new kernel RPM has been installed, > without having to wait for a system restart to run it. Likewise, when > a kernel RPM is removed, it would like to be able to run to remove > modules managed by it. Use triggers - this functionality already exists without kernel-specific infrastructure. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, Feb 18, 2008 at 12:35:19PM -0500, Don Zickus wrote: > On Sat, Feb 16, 2008 at 09:53:26AM -0600, Matt Domsch wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=433121 > > > > DKMS would like to have the opportunity to run it's > > auto-rebuilder/installer after a new kernel RPM has been installed, > > without having to wait for a system restart to run it. Likewise, when > > a kernel RPM is removed, it would like to be able to run to remove > > modules managed by it. > > > > Debian kernels intentionally run scripts located in > > /etc/kernel/postinst.d/ following new kernel package installation, > > /etc/kernel/prerm.d/ before kernel package removal. DKMS drops a > > script into these directories, to perform the appropriate actions. > > > > I want Fedora and RHEL kernels to do likewise. Patch attached. > > This patch implements the same interface as that used for Debian and > > Ubuntu kernels. The scripts are invoked with $1 = kernel version, and > > $2 = path to vmlinuz file. (DKMS doesn't need $2, but I'm keeping the > > interface the same to match so people can reuse their scriptlets.) > > I argued against this idea in RHEL because I believe blindly running > random scripts in a directory is an unsafe thing to do (despite its best > intentions it can still be abused). > > Also from a support perspective, it becomes more complicated to support > kernel installs when random user scripts can cause unknown behaviour. This has been the argument against DKMS for 5 years now. However, in those 5 years, how many support calls has Red Hat taken where a DKMS-ified driver turned out to be the problem? Where it wasn't obvious what was happening? 'dkms status' is even part of sysreport, and has been for at least 3 years. I'd accept a change to new-kernel-package rpmposttrans() that invokes the DKMS script directly, as opposed to looping through a plug-in directory, if that makes people feel any better. I suspect it doesn't though. Waiting on a higher-level tool to assist the support guys ask for 'dkms status' info may be appropriate for RHEL, but not for Fedora. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Sat, Feb 16, 2008 at 09:53:26AM -0600, Matt Domsch wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=433121 > > DKMS would like to have the opportunity to run it's > auto-rebuilder/installer after a new kernel RPM has been installed, > without having to wait for a system restart to run it. Likewise, when > a kernel RPM is removed, it would like to be able to run to remove > modules managed by it. > > Debian kernels intentionally run scripts located in > /etc/kernel/postinst.d/ following new kernel package installation, > /etc/kernel/prerm.d/ before kernel package removal. DKMS drops a > script into these directories, to perform the appropriate actions. > > I want Fedora and RHEL kernels to do likewise. Patch attached. > This patch implements the same interface as that used for Debian and > Ubuntu kernels. The scripts are invoked with $1 = kernel version, and > $2 = path to vmlinuz file. (DKMS doesn't need $2, but I'm keeping the > interface the same to match so people can reuse their scriptlets.) I argued against this idea in RHEL because I believe blindly running random scripts in a directory is an unsafe thing to do (despite its best intentions it can still be abused). Also from a support perspective, it becomes more complicated to support kernel installs when random user scripts can cause unknown behaviour. The RHEL thread started investigating the idea of a hook into an event mechanism provided by a high level install app with the appropriate logging. The idea was to clearly separate a successful kernel install from a poorly executed posttrans script. This way developers didn't waste their time trying to reproduce something that we clearly did not support. Jon M. can probably fill you in better. Cheers, Don ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote: > Matt Domsch ([EMAIL PROTECTED]) said: > > > Use triggers - this functionality already exists without kernel-specific > > > infrastructure. > > > > a) LSB suggests triggers are evil. > > Then triggers must be the right answer. :-) > > b) triggers don't tell me the version of the package that got > >installed that caused the trigger, which is what I need to know. > > > Hm, I wonder if this can be added to RPM. c) I need them to run at the end of the transaction, when I can expect both kernel and kernel-devel to have been installed in the same transaction. Right now triggers run following the %post of the new kernel install, which is too early if both kernel-devel and kernel RPMs are being installed; there's no ordering guarantee between the two such that we know kernel-devel is always installed before kernel. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, Feb 18, 2008 at 12:01:23PM -0600, Matt Domsch wrote: > On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote: > > Matt Domsch ([EMAIL PROTECTED]) said: > > > > Use triggers - this functionality already exists without kernel-specific > > > > infrastructure. > > > > > > a) LSB suggests triggers are evil. > > > > Then triggers must be the right answer. > > :-) > > > > b) triggers don't tell me the version of the package that got > > >installed that caused the trigger, which is what I need to know. > > > > > > Hm, I wonder if this can be added to RPM. > > > c) I need them to run at the end of the transaction, when I can expect > both kernel and kernel-devel to have been installed in the same > transaction. Right now triggers run following the %post of the new > kernel install, which is too early if both kernel-devel and kernel > RPMs are being installed; there's no ordering guarantee between the > two such that we know kernel-devel is always installed before kernel. Curious, what happens if someone just wants to install the kernel, no -devel package? Does the posttrans fail? Maybe I should go re-read the patch. :) Cheers, Don ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, Feb 18, 2008 at 01:13:35PM -0500, Don Zickus wrote: > On Mon, Feb 18, 2008 at 12:01:23PM -0600, Matt Domsch wrote: > > On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote: > > > Matt Domsch ([EMAIL PROTECTED]) said: > > > > > Use triggers - this functionality already exists without > > > > > kernel-specific > > > > > infrastructure. > > > > > > > > a) LSB suggests triggers are evil. > > > > > > Then triggers must be the right answer. > > > > :-) > > > > > > b) triggers don't tell me the version of the package that got > > > >installed that caused the trigger, which is what I need to know. > > > > > > > > > Hm, I wonder if this can be added to RPM. > > > > > > c) I need them to run at the end of the transaction, when I can expect > > both kernel and kernel-devel to have been installed in the same > > transaction. Right now triggers run following the %post of the new > > kernel install, which is too early if both kernel-devel and kernel > > RPMs are being installed; there's no ordering guarantee between the > > two such that we know kernel-devel is always installed before kernel. > > Curious, what happens if someone just wants to install the kernel, no > -devel package? Does the posttrans fail? Maybe I should go re-read the > patch. :) no, new-kernel-pkg exits with status 0 from rpmposttrans() regardless of if the scripts it's invoking succeed or fail. No reason to hork up RPM over it. The DKMS script itself will fail if there's no matching kernel-devel package present, or if there's no compiler present, etc. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
> "MD" == Matt Domsch <[EMAIL PROTECTED]> writes: MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel. It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering. - J< ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, Feb 18, 2008 at 12:45:05PM -0500, Bill Nottingham wrote: > Matt Domsch ([EMAIL PROTECTED]) said: > > https://bugzilla.redhat.com/show_bug.cgi?id=433121 > > > > DKMS would like to have the opportunity to run it's > > auto-rebuilder/installer after a new kernel RPM has been installed, > > without having to wait for a system restart to run it. Likewise, when > > a kernel RPM is removed, it would like to be able to run to remove > > modules managed by it. > > Use triggers - this functionality already exists without kernel-specific > infrastructure. a) LSB suggests triggers are evil. b) triggers don't tell me the version of the package that got installed that caused the trigger, which is what I need to know. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
Matt Domsch ([EMAIL PROTECTED]) said: > > Use triggers - this functionality already exists without kernel-specific > > infrastructure. > > a) LSB suggests triggers are evil. Then triggers must be the right answer. > b) triggers don't tell me the version of the package that got >installed that caused the trigger, which is what I need to know. Hm, I wonder if this can be added to RPM. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, Feb 18, 2008 at 11:48:41AM -0600, Matt Domsch wrote: > > Also from a support perspective, it becomes more complicated to support > > kernel installs when random user scripts can cause unknown behaviour. > > This has been the argument against DKMS for 5 years now. However, in > those 5 years, how many support calls has Red Hat taken where a > DKMS-ified driver turned out to be the problem? Where it wasn't > obvious what was happening? 'dkms status' is even part of sysreport, > and has been for at least 3 years. I was unaware of this. But in rhel we have been adding more support to make it more obvious that non-rhel drivers have been installed. Perhaps that will help support. Most reports I read though usually have the statement "does it work without the 3rd-party driver". > > I'd accept a change to new-kernel-package rpmposttrans() that invokes > the DKMS script directly, as opposed to looping through a plug-in > directory, if that makes people feel any better. I suspect it doesn't > though. I would be more in favor of that provided we shipped and controled the script. Something an 'rpm -v' could verify that the script wasn't maliciously changed. > > Waiting on a higher-level tool to assist the support guys ask for > 'dkms status' info may be appropriate for RHEL, but not for Fedora. My opinion is support shouldn't have to use 'dkms status' at all, it should be obvious that 3rd-party modules are loaded (i assume 'dkms status' just reports that as I'm not familiar with the tool). Cheers, Don ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
Jason L Tibbitts III ([EMAIL PROTECTED]) said: > > "MD" == Matt Domsch <[EMAIL PROTECTED]> writes: > > MD> [...] there's no ordering guarantee between the two such that we > MD> know kernel-devel is always installed before kernel. > > It should be possible to have kernel-devel have Requires(post): kernel > or use some other type of fine-grained dependency to guarantee some > sort of ordering. Is that good enough? It should be easily implementable. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
Peter Jones wrote: (Adding Panu to the Cc) Jason L Tibbitts III wrote: "MD" == Matt Domsch <[EMAIL PROTECTED]> writes: MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel. It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering. That doesn't guarantee the right thing -- it's inverted. It makes it so that before kernel-devel's %post runs, kernel must be installed. What Matt needs is a guarantee that kernel-devel is installed (if it will be installed at all) before kernel's %post runs. Right now the only way to do that is for kernel to require(post): kernel-devel, which is obviously not something we want to do. Actually, I guess that's not the only way -- there is %posttrans . It has some obvious downsides though, not least of which being if the transaction fails it'll never get run, it doesn't show up in any progress information, and AFAIK it's generally just not well tested. -- Peter ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
> "PJ" == Peter Jones <[EMAIL PROTECTED]> writes: PJ> That doesn't guarantee the right thing -- it's inverted. It makes PJ> it so that before kernel-devel's %post runs, kernel must be PJ> installed. What Matt needs is a guarantee that kernel-devel is PJ> installed (if it will be installed at all) before kernel's %post PJ> runs. Well, since kernel-devel is the package that's actually the one you need to do anything, can't you just trigger on kernel-devel installs? - J< ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, Feb 18, 2008 at 01:42:49PM -0600, Jason L Tibbitts III wrote: > > "PJ" == Peter Jones <[EMAIL PROTECTED]> writes: > > PJ> That doesn't guarantee the right thing -- it's inverted. It makes > PJ> it so that before kernel-devel's %post runs, kernel must be > PJ> installed. What Matt needs is a guarantee that kernel-devel is > PJ> installed (if it will be installed at all) before kernel's %post > PJ> runs. > > Well, since kernel-devel is the package that's actually the one you > need to do anything, can't you just trigger on kernel-devel installs? no, because if DKMS decides it needs to call mkinitrd again, it needs to have kernel installed. It really is a "both and please", hence %posttrans gets us that. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
(Adding Panu to the Cc) Jason L Tibbitts III wrote: "MD" == Matt Domsch <[EMAIL PROTECTED]> writes: MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel. It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering. That doesn't guarantee the right thing -- it's inverted. It makes it so that before kernel-devel's %post runs, kernel must be installed. What Matt needs is a guarantee that kernel-devel is installed (if it will be installed at all) before kernel's %post runs. Right now the only way to do that is for kernel to require(post): kernel-devel, which is obviously not something we want to do. We've definitely mentioned that non-dependency ordering tags are an rpm wishlist item in the past. Maybe Panu has some thoughts on this? -- Peter ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
