5:58 a.m.
Hi,
I suggest to vote through email about replacing the current kernel
scheme with the kmdl or similar scheme.
a) kernel module scheme needs uname-r-in-name
b) kernel module scheme needs one-specfile approach (for both usreland
and kernel modules)
c) kernel module scheme needs to be kernel agnostic (both version
*and* flavour)
d) support for coinstallation of kmdls should be pushed into FC6 asap
(working plugin has already been submitted here and tested be
ATrpms users). Requires a positive vote on a-c)
e) Adoption of kmdl interface scheme as used at ATrpms and outlined on
http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive
vote on a-d)
f) Assignment to kmdl-task force to integrate kmdl support into the
buildsystems used by Fedora (myself volunteering). Requires a
positive vote on a-e)
g) Allow kmdl package submissions to Fedora Core/Extras. Requires a
positive vote on a-f)
Without voting, but dependent on vote results: Assist in GFS kmdl
packaging (altready done at FC4 times, needs to resurface).
--
Axel.Thimm at ATrpms.net
3:43 p.m.
On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote:
d) support for coinstallation of kmdls should be pushed into FC6
asap
(working plugin has already been submitted here and tested be
ATrpms users). Requires a positive vote on a-c)
Rather than vote on these issues as Axel suggests (which we can
certainly do), I think that perhaps we should look at a different
approach:
Just throwing it out here, but I don't really see consensus on this
issue. People either like kmod or kmdl, and I think there are definite
pros/cons to each approach. My instinct is that if we vote on Axel's
items, they will not pass. And I don't think it is because the kmdl
standard is broken or outright wrong, I think much of it is due to the
fact that so much pain and effort went into making the kmod standard
(which works for the majority of cases) that people are honestly
unwilling to start over.
So, here's the heretical proposition:
How about we permit either kmod OR kmdl as an acceptable standard? E.g.
Document both, and let the packager choose?
I see kernel module packaging as one of the last barriers to bringing in
contributions from open source, unencumbered 3rd party repo packages.
Given the near religious nature of this debate, maybe a little
flexibility (not infinite flexibility) is merited here for the greater
good?
Thoughts?
~spot
--
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
3:53 p.m.
On Fri, 2006-08-11 at 15:43 -0500, Tom 'spot' Callaway wrote:
On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote:
> d) support for coinstallation of kmdls should be pushed into FC6 asap
> (working plugin has already been submitted here and tested be
> ATrpms users). Requires a positive vote on a-c)
Rather than vote on these issues as Axel suggests (which we can
certainly do), I think that perhaps we should look at a different
approach:
Just throwing it out here, but I don't really see consensus on this
issue. People either like kmod or kmdl, and I think there are definite
pros/cons to each approach. My instinct is that if we vote on Axel's
items, they will not pass. And I don't think it is because the kmdl
standard is broken or outright wrong, I think much of it is due to the
fact that so much pain and effort went into making the kmod standard
(which works for the majority of cases) that people are honestly
unwilling to start over.
So, here's the heretical proposition:
How about we permit either kmod OR kmdl as an acceptable standard? E.g.
Document both, and let the packager choose?
I see kernel module packaging as one of the last barriers to bringing in
contributions from open source, unencumbered 3rd party repo packages.
Given the near religious nature of this debate, maybe a little
flexibility (not infinite flexibility) is merited here for the greater
good?
umm - then we'll need both plugins and it will be near impossible to
make sure they play nicely.
moreover - if a package switches owners and one likes kmod while the
previous one likes kmdl then we're kinda, umm, screwed.
the packaging committee should make a choice, go with and then it is
done.
that's the whole point of the committee.
-sv
2:01 a.m.
seth vidal schrieb:
On Fri, 2006-08-11 at 15:43 -0500, Tom 'spot' Callaway
wrote:
> On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote:
>
>> d) support for coinstallation of kmdls should be pushed into FC6 asap
>> (working plugin has already been submitted here and tested be
>> ATrpms users). Requires a positive vote on a-c)
> Rather than vote on these issues as Axel suggests (which we can
> certainly do), I think that perhaps we should look at a different
> approach:
>
> Just throwing it out here, but I don't really see consensus on this
> issue. People either like kmod or kmdl, and I think there are definite
> pros/cons to each approach. My instinct is that if we vote on Axel's
> items, they will not pass. And I don't think it is because the kmdl
> standard is broken or outright wrong, I think much of it is due to the
> fact that so much pain and effort went into making the kmod standard
> (which works for the majority of cases) that people are honestly
> unwilling to start over.
>
> So, here's the heretical proposition:
>
> How about we permit either kmod OR kmdl as an acceptable standard? E.g.
> Document both, and let the packager choose?
>
> I see kernel module packaging as one of the last barriers to bringing in
> contributions from open source, unencumbered 3rd party repo packages.
> Given the near religious nature of this debate, maybe a little
> flexibility (not infinite flexibility) is merited here for the greater
> good?
umm - then we'll need both plugins and it will be near impossible to
make sure they play nicely.
moreover - if a package switches owners and one likes kmod while the
previous one likes kmdl then we're kinda, umm, screwed.
And we need proper support for both standards in plague.
And having two standard is confusing for the users, too.
the packaging committee should make a choice, go with and then it is
done.
that's the whole point of the committee.
+1
Cu
thl
7:14 a.m.
On Fri, 2006-08-11 at 16:53 -0400, seth vidal wrote:
On Fri, 2006-08-11 at 15:43 -0500, Tom 'spot' Callaway
wrote:
> On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote:
>
> > d) support for coinstallation of kmdls should be pushed into FC6 asap
> > (working plugin has already been submitted here and tested be
> > ATrpms users). Requires a positive vote on a-c)
>
> Rather than vote on these issues as Axel suggests (which we can
> certainly do), I think that perhaps we should look at a different
> approach:
>
> Just throwing it out here, but I don't really see consensus on this
> issue. People either like kmod or kmdl, and I think there are definite
> pros/cons to each approach. My instinct is that if we vote on Axel's
> items, they will not pass. And I don't think it is because the kmdl
> standard is broken or outright wrong, I think much of it is due to the
> fact that so much pain and effort went into making the kmod standard
> (which works for the majority of cases) that people are honestly
> unwilling to start over.
>
> So, here's the heretical proposition:
>
> How about we permit either kmod OR kmdl as an acceptable standard? E.g.
> Document both, and let the packager choose?
>
> I see kernel module packaging as one of the last barriers to bringing in
> contributions from open source, unencumbered 3rd party repo packages.
> Given the near religious nature of this debate, maybe a little
> flexibility (not infinite flexibility) is merited here for the greater
> good?
umm - then we'll need both plugins and it will be near impossible to
make sure they play nicely.
moreover - if a package switches owners and one likes kmod while the
previous one likes kmdl then we're kinda, umm, screwed.
+1
Having both standards mix and match is by far the worst of both worlds
IMNSHO.
the packaging committee should make a choice, go with and then it is
done.
that's the whole point of the committee.
Another +1
Both choices have their weak and strong points. If it's impossible to
decide based on technical merits alone... flip a coin or something,
really.
- Panu -
8:31 a.m.
On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
Both choices have their weak and strong points. If it's
impossible to
decide based on technical merits alone... flip a coin or something,
really.
Or continue to use the current one that is being used by current packages in
Extras, and in RHEL.
--
Jesse Keating
Release Engineer: Fedora
10:18 a.m.
On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote:
On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
> Both choices have their weak and strong points. If it's impossible
> to decide based on technical merits alone... flip a coin or
> something, really.
Or continue to use the current one that is being used by current
packages in Extras, and in RHEL.
and which cannot be used for manual rpm installations, breaks all
depsolvers, endangers your running setup or the total upgradablity of
the system and the ugly workarounds trying to fix this turn out to
introduce more bugs that they fix making the depsolver support a
maintenance nightmare.
Workaround 1: assume rpm -i is in order, add "kernel-modules"
coinstall support in yum proper
Workaround 2: find out that the coinstall support is not enough,
additionally write a plugin
Workaround 3: find out that rpm -i isn't the proper mode, try to fix
the plugin for yum, despair on rpm
Workaround 4: find out that the plugin for yum is still incomplete and
possibly cannot be ever fixed.
Workaround 5: Impose restrictions on kernel modules and their usage so
that unfixable bugs are not triggered [*].
In contrast to well behaved rpm, yum and all other from the very start
and a trivial plugin to make yum usage more comfortable not even
needeing special "kernel-modules" support?
FYI there is exatly 1 (one) package in extras using the kernel module
scheme and RHEL is just being taught kmods (GFS) - it's not too late to
avoid RHEL5 ship with such a broken scheme unless we decide to discuss
this forever.
[*] Like
- never use rpm cli
- never have dependencies of kernel module packages on other
packages (breaks GFS/cman/dlm/...)
--
Axel.Thimm at ATrpms.net
8:44 a.m.
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote:
> On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
> > Both choices have their weak and strong points. If it's impossible
> > to decide based on technical merits alone... flip a coin or
> > something, really.
>
> Or continue to use the current one that is being used by current
> packages in Extras, and in RHEL.
and which cannot be used for manual rpm installations, breaks all
depsolvers, endangers your running setup or the total upgradablity of
the system and the ugly workarounds trying to fix this turn out to
introduce more bugs that they fix making the depsolver support a
maintenance nightmare.
To be fair, the only change to kmod that would be necessary to remove
all of this "it won't work for manual rpm installations" is the addition
of kver in the Name field.
So far, the only technical reason that I've heard mentioned here against
adding kver to Name is that it would make debuginfo more complicated for
kmod packages (and I believe that someone posted a workaround method).
In fact, I suspect that kmodtool could even include the necessary magic.
~spot
--
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
9:06 a.m.
Tom 'spot' Callaway schrieb:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
So far, the only technical reason that I've heard mentioned here against
adding kver to Name is that it would make debuginfo more complicated for
kmod packages (and I believe that someone posted a workaround method).
You forgot the biggest "issue" (note the quotes): All the depsolvers
would need special handling to install kmods for newly installed
kernels. That works out of the box with the current scheme and IMHO is
an important advantage of the current standard. Yes, there exists a
yum-plugin already that handles it. But we would need something for
up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
In fact, I suspect that kmodtool could even include the necessary
magic.
Sure, that would be possible. But we'll hit other problems after this
major scheme change. We probably hit some in the old livna days, but I
forget most of them already (sorry -- maybe I can skip though bugzilla
to fresh up my mind). But I think sticking to the current scheme and
solving the "install-conflicts" problem together with the kabi stuff
would be the better idea.
CU
thl
9:26 a.m.
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
Tom 'spot' Callaway schrieb:
> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
>
> So far, the only technical reason that I've heard mentioned here against
> adding kver to Name is that it would make debuginfo more complicated for
> kmod packages (and I believe that someone posted a workaround method).
You forgot the biggest "issue" (note the quotes): All the depsolvers
would need special handling to install kmods for newly installed
kernels. That works out of the box with the current scheme and IMHO is
an important advantage of the current standard. Yes, there exists a
yum-plugin already that handles it. But we would need something for
up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
I'm not sure I see how this automatically works in the current kmod
scheme (or alternately, how it doesn't work in the kmod+kver scheme).
> In fact, I suspect that kmodtool could even include the
necessary magic.
Sure, that would be possible. But we'll hit other problems after this
major scheme change. We probably hit some in the old livna days, but I
forget most of them already (sorry -- maybe I can skip though bugzilla
to fresh up my mind). But I think sticking to the current scheme and
solving the "install-conflicts" problem together with the kabi stuff
would be the better idea.
Again, I tend to defer to people who know more about packaging kernel
modules than I do.
~spot
--
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
11:02 a.m.
Tom 'spot' Callaway schrieb:
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
> Tom 'spot' Callaway schrieb:
>> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
>>
>> So far, the only technical reason that I've heard mentioned here against
>> adding kver to Name is that it would make debuginfo more complicated for
>> kmod packages (and I believe that someone posted a workaround method).
> You forgot the biggest "issue" (note the quotes): All the depsolvers
> would need special handling to install kmods for newly installed
> kernels. That works out of the box with the current scheme and IMHO is
> an important advantage of the current standard. Yes, there exists a
> yum-plugin already that handles it. But we would need something for
> up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
I'm not sure I see how this automatically works in the current kmod
scheme
Example (without a special plugin):
---
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-1.2.2.6.17-1.2157_FC5
kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed
to the repo
Yum will install:
kernel-2.6.17-1.2171_FC5
kmod-foo-1.2.2.6.17-1.2171_FC5
---
(or alternately, how it doesn't work in the kmod+kver scheme).
Example (without a special plugin):
---
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-2.6.17-1.2157_FC5-1.2
kernel-2.6.17-1.2171_FC5 and kmod-foo-2.6.17-1.2171_FC5-1.2 are pushed
to the repo
Yum will install:
kernel-2.6.17-1.2171_FC5
kmod-foo-2.6.17-1.2171_FC5-1.2 won't get installed because it a new
package for yum whit a different name
---
>> In fact, I suspect that kmodtool could even include the
necessary magic.
> Sure, that would be possible. But we'll hit other problems after this
> major scheme change. We probably hit some in the old livna days, but I
> forget most of them already (sorry -- maybe I can skip though bugzilla
> to fresh up my mind). But I think sticking to the current scheme and
> solving the "install-conflicts" problem together with the kabi stuff
> would be the better idea.
Again, I tend to defer to people who know more about packaging kernel
modules than I do.
I'll outline my idea in a more detailed mail I'll start preparing now.
CU
thl
2:33 p.m.
On Mon, Aug 14, 2006 at 06:02:51PM +0200, Thorsten Leemhuis wrote:
Tom 'spot' Callaway schrieb:
> On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
>> Tom 'spot' Callaway schrieb:
>>> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
>>>
>>> So far, the only technical reason that I've heard mentioned here
against
>>> adding kver to Name is that it would make debuginfo more complicated for
>>> kmod packages (and I believe that someone posted a workaround method).
>> You forgot the biggest "issue" (note the quotes): All the depsolvers
>> would need special handling to install kmods for newly installed
>> kernels. That works out of the box with the current scheme and IMHO is
>> an important advantage of the current standard. Yes, there exists a
>> yum-plugin already that handles it. But we would need something for
>> up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
>
> I'm not sure I see how this automatically works in the current kmod
> scheme
Example (without a special plugin):
---
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-1.2.2.6.17-1.2157_FC5
kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed
to the repo
Yum will install:
kernel-2.6.17-1.2171_FC5
kmod-foo-1.2.2.6.17-1.2171_FC5
---
(or alternately, how it doesn't work in the kmod+kver scheme).
Example (without a special plugin):
---
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-2.6.17-1.2157_FC5-1.2
kernel-2.6.17-1.2171_FC5 and kmod-foo-2.6.17-1.2171_FC5-1.2 are pushed
to the repo
Yum will install:
kernel-2.6.17-1.2171_FC5
kmod-foo-2.6.17-1.2171_FC5-1.2 won't get installed because it a new
package for yum whit a different name
---
>>> In fact, I suspect that kmodtool could even include the necessary magic.
>> Sure, that would be possible. But we'll hit other problems after this
>> major scheme change. We probably hit some in the old livna days, but I
>> forget most of them already (sorry -- maybe I can skip though bugzilla
>> to fresh up my mind). But I think sticking to the current scheme and
>> solving the "install-conflicts" problem together with the kabi stuff
>> would be the better idea.
>
> Again, I tend to defer to people who know more about packaging kernel
> modules than I do.
I'll outline my idea in a more detailed mail I'll start preparing now.
CU
thl
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
Thorsten,
+1
This lack of functionality is a complete show stopper. I've been using
a very similar method to the kmod example above for 6+ years. Its not
been Pain Free(tm) but I have to have an automated system of deploying
updates and kernel modules. Its just not an option or something that I
will gladly re-invent.
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
7:01 p.m.
On Mon, Aug 14, 2006 at 06:02:51PM +0200, Thorsten Leemhuis wrote:
Tom 'spot' Callaway schrieb:
> On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
>> Tom 'spot' Callaway schrieb:
>>> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
>>>
>>> So far, the only technical reason that I've heard mentioned here
against
>>> adding kver to Name is that it would make debuginfo more complicated for
>>> kmod packages (and I believe that someone posted a workaround method).
>> You forgot the biggest "issue" (note the quotes): All the depsolvers
>> would need special handling to install kmods for newly installed
>> kernels. That works out of the box with the current scheme and IMHO is
>> an important advantage of the current standard. Yes, there exists a
>> yum-plugin already that handles it. But we would need something for
>> up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
>
> I'm not sure I see how this automatically works in the current kmod
> scheme
Example (without a special plugin):
---
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-1.2.2.6.17-1.2157_FC5
kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed
to the repo
Yum will install:
kernel-2.6.17-1.2171_FC5
kmod-foo-1.2.2.6.17-1.2171_FC5
---
Example:
kmod-foo-1.3.2.6.17-1.2171_FC5 is pushed to the repo
- yum update will bail out of file conflicts
- OR will happily coinstall if the paths are disambiguated (worse)
Example (yum w/o special plugin and special kernel-modules handling in
core):
- kmod-foo-1.2.2.6.17-1.2157_FC5 get nuked. Oops ...
--
Axel.Thimm at ATrpms.net
10:02 a.m.
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
You forgot the biggest "issue" (note the quotes): All the
depsolvers
would need special handling to install kmods for newly installed
kernels. That works out of the box with the current scheme and IMHO is
an important advantage of the current standard. Yes, there exists a
yum-plugin already that handles it. But we would need something for
up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
up2date/rhel5 isn't an issue.
rhel5 is basing off of yum - like fedora is. So the plugins available
here can be used there, too.
-sv
10:30 a.m.
seth vidal schrieb:
rhel5 is basing off of yum - like fedora is. So the plugins
available
here can be used there, too.
Ohh, didn't know that. Interesting.
BTW, why isn't jcmasters (the men behind the kabi stuff for RHEL)
participating in this discussion? Is he on holiday (i poked hime once
via e-mail but I got no response)? I think it's important to get him
involved in this discussion.
CU
thl
10:41 a.m.
On Mon, Aug 14, 2006 at 11:02:35AM -0400, seth vidal wrote:
On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote:
> Yes, there exists a yum-plugin already that handles it. But we
> would need something for up2date/RHEL5 too in case the ABI breaks
> -- I suspect that's to late.
Just FYI the kernel api/abi between RHEL4U3 and RHEL4U4 broke again at
least in the wireless extensions submodule. I don't think that this
will be different with RHEL5U<N> --> U<N+1> updates.
up2date/rhel5 isn't an issue.
rhel5 is basing off of yum - like fedora is. So the plugins available
here can be used there, too.
That's good news. Does that mean that yum has rhn support?
I started shipping the kmdl plugin to ATrpms' users, but would prefer
it to get into yum-utils as a subpackage. If approved should I send
you a patch for CVS and one for the specfile?
--
Axel.Thimm at ATrpms.net
10:33 a.m.
On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote:
You forgot the biggest "issue" (note the quotes): All the
depsolvers
would need special handling to install kmods for newly installed
kernels. That works out of the box with the current scheme and IMHO is
an important advantage of the current standard. Yes, there exists a
yum-plugin already that handles it. But we would need something for
up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
o the yum-plugin for kmods is broken and possibly cannot be rectified,
see mail to Jack
o "out of the box" the current scheme is severely broken. In yum you get
file conflicts, in rpm total breakage and in smart/apt you get your
running kernel modules nuked.
You make it sound like the kmdl scheme needs special handling, while
it's the other way round. The kmdl scheme does never jeopardize your
existing install and this inherits to all depsolvers and rpm. While
the kmod scheme violates basic rpm ordering rules and tried to rectify
with in-depsolver special handling *and* plugins and has already been
shown to be broken by design.
--
Axel.Thimm at ATrpms.net
2:49 p.m.
On Mon, Aug 14, 2006 at 05:33:10PM +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote:
> You forgot the biggest "issue" (note the quotes): All the depsolvers
> would need special handling to install kmods for newly installed
> kernels. That works out of the box with the current scheme and IMHO is
> an important advantage of the current standard. Yes, there exists a
> yum-plugin already that handles it. But we would need something for
> up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
o the yum-plugin for kmods is broken and possibly cannot be rectified,
see mail to Jack
Ah, breakage. Tisk, tisk. Solve this one:
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-2.6.17-1.2157_FC5-1.2
foo-1.2-1_FC5
where kmod-foo-1.2.2.6.17-1.2157_FC5 requires foo = 1.2
Yum has:
kernel-2.6.17-1.2171_FC5
kmod-foo-2.6.17-1.2171_FC5-1.3
foo-1.3_FC5
And kmod-foo-2.6.17-1.2171_FC5-1.2 requires foo = 1.3.
So what happens here?
# yum update
We reboot into our new kernel and 10 minutes later we see that foo is
totally broken because there's not a kernel module for it.
# yum install kmod-foo-2.6.17-1.2171_FC5
Yum pulls in foo-1.3 to meet the requirements. Now we experiance pain
as foo-1.2 and foo-1.3 are userland packages and cannot be co-installed.
This affects both schemes. Is this a technical problem that can be
fixed?
o "out of the box" the current scheme is severely broken. In yum you get
file conflicts, in rpm total breakage and in smart/apt you get your
running kernel modules nuked.
I did this with Yup (of all horrid, gross, gangly things) 6 years ago
with a bit of documentation/policy.
You make it sound like the kmdl scheme needs special handling, while
it's the other way round. The kmdl scheme does never jeopardize your
existing install and this inherits to all depsolvers and rpm. While
the kmod scheme violates basic rpm ordering rules and tried to rectify
with in-depsolver special handling *and* plugins and has already been
shown to be broken by design.
--
Axel.Thimm at ATrpms.net
The kmdl scheme *does* require depsolver modifications to work. I must be
able to push out updated kernel modules to my clients in an automated
fashion.
Jack
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
6:26 p.m.
On Mon, Aug 14, 2006 at 03:49:50PM -0400, Jack Neely wrote:
On Mon, Aug 14, 2006 at 05:33:10PM +0200, Axel Thimm wrote:
> On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote:
> > You forgot the biggest "issue" (note the quotes): All the depsolvers
> > would need special handling to install kmods for newly installed
> > kernels. That works out of the box with the current scheme and IMHO is
> > an important advantage of the current standard. Yes, there exists a
> > yum-plugin already that handles it. But we would need something for
> > up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late.
>
> o the yum-plugin for kmods is broken and possibly cannot be rectified,
> see mail to Jack
Ah, breakage. Tisk, tisk. Solve this one:
Altready solved since long in ATrpms' everyday life.
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-2.6.17-1.2157_FC5-1.2
foo-1.2-1_FC5
where kmod-foo-1.2.2.6.17-1.2157_FC5 requires foo = 1.2
Yum has:
kernel-2.6.17-1.2171_FC5
kmod-foo-2.6.17-1.2171_FC5-1.3
foo-1.3_FC5
And kmod-foo-2.6.17-1.2171_FC5-1.2 requires foo = 1.3.
You probably have a typo here, the first item is supposed to end with
1.3
So what happens here?
You are trying to do both a kernel upgrade and module version
upgrade. You only get into that situation because you skipped the
intermediate step (which can happen simultaneously): You don't only
build mod-foo-2.6.17-1.2171_FC5-1.3, you also build
kmod-foo-2.6.17-1.2157_FC5-1.3.
# yum update
Updates everything to 1.3
We reboot into our new kernel and 10 minutes later we see that foo
is
totally broken because there's not a kernel module for it.
Only if you messed up by simultaneous upgrading kernel and module
version w/o offering interim versions.
# yum install kmod-foo-2.6.17-1.2171_FC5
Yum pulls in foo-1.3 to meet the requirements. Now we experiance pain
as foo-1.2 and foo-1.3 are userland packages and cannot be co-installed.
Note that kernel modules have two version (evrs to be exact):
o the kernel version: follows the kernel's example and allows going
back and forth
o the module version: follows a conventional package's upgrading
If the new kernel is broken you can reboot to the previous one. If the
module itself is bogus you need to downgrade as you do with
conventional packages.
This affects both schemes. Is this a technical problem that can be
fixed?
Not a problem with kmdls.
> You make it sound like the kmdl scheme needs special handling,
while
> it's the other way round. The kmdl scheme does never jeopardize your
> existing install and this inherits to all depsolvers and rpm. While
> the kmod scheme violates basic rpm ordering rules and tried to rectify
> with in-depsolver special handling *and* plugins and has already been
> shown to be broken by design.
The kmdl scheme *does* require depsolver modifications to work. I must be
able to push out updated kernel modules to my clients in an automated
fashion.
Once again arguing in circles, but repetions works:
o kmod scheme: requires workaround in yum core and requires a yum
plugin to not start nuking running kernel modules or file
conflicting or partial overwrites
o kmdl scheme: requires trivial yum plugin to have new kernel installs
automatically coinstall kmdls
Note both say "requires", but the first is requires as in "requires,
otherwise havoc is programmed", while the latter is "requires for
added comfort"
Yes, let's allow kmdls to become more comfortable, but don't compare
neccessity of (trying to) unbreak things with adding automatism.
--
Axel.Thimm at ATrpms.net
10:27 a.m.
On Mon, Aug 14, 2006 at 08:44:08AM -0500, Tom 'spot' Callaway wrote:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
> On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote:
> > On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
> > > Both choices have their weak and strong points. If it's impossible
> > > to decide based on technical merits alone... flip a coin or
> > > something, really.
> >
> > Or continue to use the current one that is being used by current
> > packages in Extras, and in RHEL.
>
> and which cannot be used for manual rpm installations, breaks all
> depsolvers, endangers your running setup or the total upgradablity of
> the system and the ugly workarounds trying to fix this turn out to
> introduce more bugs that they fix making the depsolver support a
> maintenance nightmare.
To be fair, the only change to kmod that would be necessary to remove
all of this "it won't work for manual rpm installations" is the addition
of kver in the Name field.
It sounds like it's a minor details, but it's a major design block. If
you also agree to one specfile handling for both userland/kernelland
you end up at kmdl's versioning with a different name.
And since one does throw out the biggest design elements, why not
bring in all the other good stuff that kmdls bring with them? Nobody
objected to the rest of the benfits only the uname-r-in-name stuff is
being discussed.
--
Axel.Thimm at ATrpms.net
2:27 p.m.
On Mon, Aug 14, 2006 at 08:44:08AM -0500, Tom 'spot' Callaway wrote:
On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
> On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote:
> > On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
> > > Both choices have their weak and strong points. If it's impossible
> > > to decide based on technical merits alone... flip a coin or
> > > something, really.
> >
> > Or continue to use the current one that is being used by current
> > packages in Extras, and in RHEL.
>
> and which cannot be used for manual rpm installations, breaks all
> depsolvers, endangers your running setup or the total upgradablity of
> the system and the ugly workarounds trying to fix this turn out to
> introduce more bugs that they fix making the depsolver support a
> maintenance nightmare.
To be fair, the only change to kmod that would be necessary to remove
all of this "it won't work for manual rpm installations" is the addition
of kver in the Name field.
So far, the only technical reason that I've heard mentioned here against
adding kver to Name is that it would make debuginfo more complicated for
kmod packages (and I believe that someone posted a workaround method).
In fact, I suspect that kmodtool could even include the necessary magic.
~spot
--
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
No one has offered an explanation or yum plugin to handle scalability.
A new kernel is released. How do I push out a new kernel module to all
my machines? This scheme only appears to scale to 1 person with root on
his home machine. I need to power an entire university.
Because kmdl modules do not follow the kernel that adds yet another
reason why upgrading to the latest kernel is painful and to be avoided.
We all know where this slippery slope goes.
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
6 p.m.
On Mon, Aug 14, 2006 at 03:27:44PM -0400, Jack Neely wrote:
No one has offered an explanation or yum plugin to handle
scalability.
What about the plugin I submitted to this very list?
A new kernel is released. How do I push out a new kernel module to
all
my machines? This scheme only appears to scale to 1 person with root on
his home machine. I need to power an entire university.
yum update with the kmdl plugin is enough. You still need to be root
on all the machines though ;)
Because kmdl modules do not follow the kernel that adds yet another
reason why upgrading to the latest kernel is painful and to be avoided.
We all know where this slippery slope goes.
Of course they follow the kernel, that's what the plugin is for.
--
Axel.Thimm at ATrpms.net
10:35 a.m.
Just to give the good example. Please do your voting and let's see
where we stand. My batteries are running out, repeating the same
arguments again and again isn't fun. So let's either do it or drown
it.
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
Hi,
I suggest to vote through email about replacing the current kernel
scheme with the kmdl or similar scheme.
a) kernel module scheme needs uname-r-in-name
+1
b) kernel module scheme needs one-specfile approach (for both
usreland
and kernel modules)
+1
c) kernel module scheme needs to be kernel agnostic (both version
*and* flavour)
+1
d) support for coinstallation of kmdls should be pushed into FC6
asap
(working plugin has already been submitted here and tested be
ATrpms users). Requires a positive vote on a-c)
+1
e) Adoption of kmdl interface scheme as used at ATrpms and outlined
on
http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive
vote on a-d)
+1
f) Assignment to kmdl-task force to integrate kmdl support into the
buildsystems used by Fedora (myself volunteering). Requires a
positive vote on a-e)
+1
g) Allow kmdl package submissions to Fedora Core/Extras. Requires a
positive vote on a-f)
+1
Without voting, but dependent on vote results: Assist in GFS kmdl
packaging (altready done at FC4 times, needs to resurface).
--
Axel.Thimm at ATrpms.net
10:43 a.m.
Axel Thimm wrote:
Just to give the good example. Please do your voting and let's
see
where we stand. My batteries are running out, repeating the same
arguments again and again isn't fun. So let's either do it or drown
it.
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
> Hi,
>
> I suggest to vote through email about replacing the current kernel
> scheme with the kmdl or similar scheme.
I'd have to say that change here is warranted and Axel's proposal(s)
make the most sense to me:
afaict, a-g all +1
-- Rex
11:10 a.m.
Rex Dieter schrieb:
Axel Thimm wrote:
> On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
>> I suggest to vote through email about replacing the current kernel
>> scheme with the kmdl or similar scheme.
I'd have to say that change here is warranted and Axel's proposal(s)
make the most sense to me:
afaict, a-g all +1
Rex, could you please describe why you think this scheme it better? I'm
fine with changing details (I'm still unsure if the uname -r in NAME is
a good thing or bad), but why throw everything over board that was
developed, discussed and agreed on by the old FESCo? Are there any
problems you're seeing with the current scheme?
CU
thl
11:14 a.m.
Thorsten Leemhuis wrote:
Rex Dieter schrieb:
> Axel Thimm wrote:
>> On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
>>> I suggest to vote through email about replacing the current kernel
>>> scheme with the kmdl or similar scheme.
>
> I'd have to say that change here is warranted and Axel's proposal(s)
> make the most sense to me:
> afaict, a-g all +1
Rex, could you please describe why you think this scheme it better?
I *could* just parrot Axel's previous empteen mails on the subject... (:
In short, I found myself agreeing with his analysis of the shortcomings of
the current kmod scheme and advantages of his kmdl proposal.
-- Rex
11:43 a.m.
Axel Thimm schrieb:
a) kernel module scheme needs uname-r-in-name
+/-0 currently if we only work for Fedora here.
-1 currently if we want the same stuff in RHEL and Fedora -- the "uname
-r" is not that important with the kabi stuff and the problem should be
fixed properly.
Note the word "currently".
b) kernel module scheme needs one-specfile approach (for both
usreland
and kernel modules)
-1 ; Reasons:
- changes only in the kmod will require that the userland packages gets
rebuild, too. That unnecessary. Yes, it can be prevented manually. But
we would have to make sure that SRPMs for the old userland packages stay
in the repo; and we would need special handling in the buildsys -> can
of worms.
- people during the last kmod development didn't like having spec files
with a lot of
--
%if userland
do stuff to build userland
#endif
%if module
do stuff to build kmod
#endif
- Because the name of the SRPM doesn't change when you rebuild stuff for
a newly released kernel the name of the debuginfo packages does also not
change. So with a one-specfile approach we'd have to
-- created manually; we tried that during the development of the kmod
standard. We didn't like it
or
-- that the release in increased everytime so the new debuginfo packages
gets a new name -- creates the SRPMS problem described above
c) kernel module scheme needs to be kernel agnostic (both version
*and* flavour)
+1 -- They are agnostic already. The current hardwiring in the spec file
is only a temporary solution until we have proper support in the
buildsys. Yes, there is one place in "kmodtool" where the flavours are
hardcoded for users that rebuild kmods manually to prevent that they do
something wrong.
d) support for coinstallation of kmdls should be pushed into FC6
asap
(working plugin has already been submitted here and tested be
ATrpms users). Requires a positive vote on a-c)
-1 -- we took about half a year to develop the current standard for FE.
I'm not going to switch to something where besides Axel no one of the
people around has practical experiences
- in a hurry
- without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
- after test2
- shortly before RHEL beta 1 (or is it out already?)
I'd even tend to say: We shouldn't change what was discussed below "a)"
(see above) at this point. To risky IMHO.
e) [...] Requires a positive vote on a-d) [...]
I had to many -1 up to here, so I'm stopping now ;-)
CU
thl
11:56 a.m.
On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote:
+/-0 currently if we only work for Fedora here.
0 is equal to -1 in fedora-packaging
-1 currently if we want the same stuff in RHEL and Fedora -- the
"uname
-r" is not that important with the kabi stuff and the problem should be
fixed properly.
kabi argumentation was shown to not lead anywhere, not even with RHEL.
- changes only in the kmod will require that the userland packages
gets
rebuild, too.
Changes to glibc-devel will require rebuilding glibc, too. Should we
decompose each package into that many src.rpm as it has suppackages???
- Because the name of the SRPM doesn't change when you rebuild
stuff for
a newly released kernel the name of the debuginfo packages does also not
change.
That was addressed by Ville on this list and the full sane and
elegant solution already presented. So the rest of the argument is
bogus.
> c) kernel module scheme needs to be kernel agnostic (both
version
> *and* flavour)
+1 -- They are agnostic already. The current hardwiring in the spec file
is only a temporary solution [...]
It's hardcoded in the guidelines.
> d) support for coinstallation of kmdls should be pushed into FC6
asap
> (working plugin has already been submitted here and tested be
> ATrpms users). Requires a positive vote on a-c)
-1 -- we took about half a year to develop the current standard for FE.
I'm not going to switch to something where besides Axel no one of the
people around has practical experiences
- in a hurry
- without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
- after test2
- shortly before RHEL beta 1 (or is it out already?)
I'd even tend to say: We shouldn't change what was discussed below
"a)"
(see above) at this point. To risky IMHO.
Are you are trying to subvert the voting by raising the bar too high?
The current scheme was proven to be broken, there is nothing more that
can be broken, the kmdl scheme was presented and is in practice at
ATrpms for *years*. So you have both theoretical and practical proof
on the benefits.
And please consider that you are endorsing a standard for RHEL that is
known to break the yum kmod plugin when it comes to GFS/cman
dependencies, which is the only place where FC or RHEL really use
kernel modules.
Should Fedora's heritage to RHEL be a completely broken cluster/gfs
setup or should we wait until RHEL's QA addresses upgradability, and
dumps the current scheme then? Or worse, have the customers find out?
--
Axel.Thimm at ATrpms.net
12:41 p.m.
Axel Thimm schrieb:
On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote:
> +/-0 currently if we only work for Fedora here.
0 is equal to -1 in fedora-packaging
Sorry, "0" meant undecided for me.
> -1 currently if we want the same stuff in RHEL and Fedora -- the
"uname
> -r" is not that important with the kabi stuff and the problem should be
> fixed properly.
kabi argumentation was shown to not lead anywhere, not even with RHEL.
"--verbose" please, seems I missed something here.
I prefer to have the same stuff in RHEL and Fedora -- even if it of
small use in Fedora.
> - changes only in the kmod will require that the userland
packages gets
> rebuild, too.
Changes to glibc-devel will require rebuilding glibc, too. Should we
decompose each package into that many src.rpm as it has suppackages???
Well, kmod packages in my experience need some updates now and then
(e.g. special patches for a new kernel version). I prefer to save our
users the download of a new userland package in that case.
That by itself of course doesn't warrent the split. But together with
the two other reasons I gave I think it's okay.
(Note, I didn't like the split in the beginning when we created the
current kmod standard. I really like it now that I got used to it).
> - Because the name of the SRPM doesn't change when you
rebuild stuff for
> a newly released kernel the name of the debuginfo packages does also not
> change.
That was addressed by Ville on this list and the full sane and
elegant solution already presented. So the rest of the argument is
bogus.
You mean
https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html
? That stuff is what I meant with:
---
[...]
-- created manually; we tried that during the development of the kmod
standard. We didn't like it
[...]
---
in my mail you replied to.
>> c) kernel module scheme needs to be kernel agnostic (both
version
>> *and* flavour)
> +1 -- They are agnostic already. The current hardwiring in the spec file
> is only a temporary solution [...]
It's hardcoded in the guidelines.
Well, you would have to hardcode it also until the buildsys gains proper
support for your scheme. The guidelines ever state that is an interim
solution:
# stuff to be implemented externally:
[...]
# hardcode for now:
[...]
>> d) support for coinstallation of kmdls should be pushed into
FC6 asap
>> (working plugin has already been submitted here and tested be
>> ATrpms users). Requires a positive vote on a-c)
> -1 -- we took about half a year to develop the current standard for FE.
> I'm not going to switch to something where besides Axel no one of the
> people around has practical experiences
>
> - in a hurry
>
> - without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
>
> - after test2
>
> - shortly before RHEL beta 1 (or is it out already?)
>
> I'd even tend to say: We shouldn't change what was discussed below
"a)"
> (see above) at this point. To risky IMHO.
Are you are trying to subvert the voting by raising the bar too high?
The current scheme was proven to be broken
"in your opinion" is missing here. Or I lost track completely here. Yes,
there is the problem described in
https://www.redhat.com/archives/fedora-packaging/2006-August/msg00079.htmlis
But switching to a total different solution is not the only way to fix
this. Further: I got not only one bug report due to this. I got many
report due to problems when we had the "uname -r" in the name.
If I'm missing other real "problems" please enlight me. tia!
, there is nothing more that
can be broken, the kmdl scheme was presented and is in practice at
ATrpms for *years*. So you have both theoretical and practical proof
on the benefits.
The kmod scheme works fine in lvn for FC5, too. That's not years. But we
had years with problems with the other scheme that used to have "uname
-r" in the name.
And please consider that you are endorsing a standard for RHEL
I do -- that's why I'm proposing a solution based on the current one
that works on both FC and RHEL.
that is
known to break the yum kmod plugin when it comes to GFS/cman
dependencies, which is the only place where FC or RHEL really use
kernel modules.
GFS2 is in the Fedoras main kernel package for some time now. See
http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?vi...
for details. I suspect that will be the case for RHEL, too.
CU
thl
1:05 p.m.
On Mon, Aug 14, 2006 at 07:41:40PM +0200, Thorsten Leemhuis wrote:
>> -1 currently if we want the same stuff in RHEL and Fedora --
the "uname
>> -r" is not that important with the kabi stuff and the problem should be
>> fixed properly.
> kabi argumentation was shown to not lead anywhere, not even with RHEL.
"--verbose" please, seems I missed something here.
Then please check the archives it was after all an answer to a mail
from you. Alternatively please outline what you suppose any kabi stuff
will bring in other than a further delay?
I prefer to have the same stuff in RHEL and Fedora -- even if it of
small use in Fedora.
I agree and ATrpms ships kmdls for RHEL3 and RHEL4 since years,
too. Part of kmdl's design is so that RHEL3 is supported, too.
So RHEL is not an issue with kmdls, more an argument in favour of
them.
>> - changes only in the kmod will require that the userland
packages gets
>> rebuild, too.
> Changes to glibc-devel will require rebuilding glibc, too. Should we
> decompose each package into that many src.rpm as it has suppackages???
Well, kmod packages in my experience need some updates now and then
(e.g. special patches for a new kernel version). I prefer to save our
users the download of a new userland package in that case.
That by itself of course doesn't warrent the split. But together with
the two other reasons I gave I think it's okay.
Which were debunked, too. And please add the confusion of users when
say nvidia does not work. File a bug against kmdo-nvidia or nvidia?
Check changelogs of which package for what change?
>> - Because the name of the SRPM doesn't change when you
rebuild stuff for
>> a newly released kernel the name of the debuginfo packages does also not
>> change.
> That was addressed by Ville on this list and the full sane and
> elegant solution already presented. So the rest of the argument is
> bogus.
You mean
https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html
? That stuff is what I meant with:
---
[...]
-- created manually; we tried that during the development of the kmod
standard. We didn't like it
[...]
---
in my mail you replied to.
What is manual about it? It works fully transparently in the
background like the usual debuginfo stuff does. There are no manual
actions required or manual entries in specfiles. You don't even need
to patch up redhat-rpm-macros. It can't be more automatic ...
>> I'd even tend to say: We shouldn't change what was
discussed below "a)"
>> (see above) at this point. To risky IMHO.
> Are you are trying to subvert the voting by raising the bar too high?
> The current scheme was proven to be broken
"in your opinion" is missing here. Or I lost track completely here.
Everything is in my opinion of course, even that 2+2=4. Still the
current scheme factually remains broken whether it's my opinion or
not.
But switching to a total different solution is not the only way to
fix
this.
I showed inductively that uname-r-in-name is a neccessity. The other
way is to patch up rpm to use a new rpmvercmp. Not ever going to
happen IMO. The way you seem to prefer is to live with broken rpm
semantics and try to cover up with plugins that try to save the day
for yum but abandon rpm broken and only cover our eyes with dirt that
yum is working.
Further: I got not only one bug report due to this.
Lack of usage? Lack of updated packages? yum dependency calculation
abort (wrongly) attributed to something else? User totally confused on
the cause of havoc attributing it to his usage?
You know when and *that* it triggers inevitably. You don't need bug
reports for something proven to be the case. I neither have seen any
bug reports on rm -fr / being bad ...
> And please consider that you are endorsing a standard for RHEL
I do -- that's why I'm proposing a solution based on the current one
that works on both FC and RHEL.
> that is known to break the yum kmod plugin when it comes to
> GFS/cman dependencies, which is the only place where FC or RHEL
> really use kernel modules.
GFS2 is in the Fedoras main kernel package for some time now. See
http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?vi...
for details. I suspect that will be the case for RHEL, too.
Who said GFS2? GFS is "GFS1" introduced in RHEL3 and supported in
RHEL4 and RHEL5, it denotes an online format as contrasted to actual
GFS versioning (like 6.0 and 6.1). GFS will continue to live outside
the kernel package and is required to support every productive GFS
setup out there. There are no GFS2 productive setups to date (because
there is no enterprise supported solution for GFS2 yet released, RHEL5
possibly layered would be the first)
So it remains the current hertiage is a broken GFS setup for RHEL.
--
Axel.Thimm at ATrpms.net
2:58 p.m.
On Mon, Aug 14, 2006 at 06:56:15PM +0200, Axel Thimm wrote:
On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote:
> +/-0 currently if we only work for Fedora here.
0 is equal to -1 in fedora-packaging
> -1 currently if we want the same stuff in RHEL and Fedora -- the "uname
> -r" is not that important with the kabi stuff and the problem should be
> fixed properly.
kabi argumentation was shown to not lead anywhere, not even with RHEL.
> - changes only in the kmod will require that the userland packages gets
> rebuild, too.
Changes to glibc-devel will require rebuilding glibc, too. Should we
decompose each package into that many src.rpm as it has suppackages???
> - Because the name of the SRPM doesn't change when you rebuild stuff for
> a newly released kernel the name of the debuginfo packages does also not
> change.
That was addressed by Ville on this list and the full sane and
elegant solution already presented. So the rest of the argument is
bogus.
> > c) kernel module scheme needs to be kernel agnostic (both version
> > *and* flavour)
>
> +1 -- They are agnostic already. The current hardwiring in the spec file
> is only a temporary solution [...]
It's hardcoded in the guidelines.
> > d) support for coinstallation of kmdls should be pushed into FC6 asap
> > (working plugin has already been submitted here and tested be
> > ATrpms users). Requires a positive vote on a-c)
>
> -1 -- we took about half a year to develop the current standard for FE.
> I'm not going to switch to something where besides Axel no one of the
> people around has practical experiences
>
> - in a hurry
>
> - without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
>
> - after test2
>
> - shortly before RHEL beta 1 (or is it out already?)
>
> I'd even tend to say: We shouldn't change what was discussed below
"a)"
> (see above) at this point. To risky IMHO.
Are you are trying to subvert the voting by raising the bar too high?
The current scheme was proven to be broken, there is nothing more that
can be broken, the kmdl scheme was presented and is in practice at
ATrpms for *years*. So you have both theoretical and practical proof
on the benefits.
Again, show me how kmdl scales. A university/enterprise environment is
not a 3rd party extras repository.
And please consider that you are endorsing a standard for RHEL that is
known to break the yum kmod plugin when it comes to GFS/cman
dependencies, which is the only place where FC or RHEL really use
kernel modules.
You haven't addressed all my points either.
Should Fedora's heritage to RHEL be a completely broken cluster/gfs
setup or should we wait until RHEL's QA addresses upgradability, and
dumps the current scheme then? Or worse, have the customers find out?
--
Axel.Thimm at ATrpms.net
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
3:11 p.m.
On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
Again, show me how kmdl scales. A university/enterprise environment
is
not a 3rd party extras repository.
I pointed out earlier in this thread that we've used a scheme similar to
kmdl at work (speaking of thousands of systems here) rather successfully
for several years. And like I stated previously as well, this is just
for the record, I'm not arguing for either scheme.
It's not kmdl or kmod that scales, it's the processes for releasing
kernel modules and the depsolver+plugin to handle them which need to
"scale": a plugin can be smart enough to skip the kernel update if no
corresponding kernel module for the new version can be found, or abort
the entire update. But you'll need plugins for both schemes to catch the
situation where somehow a new kernel slipped out without having kernel
modules for it available, otherwise you can end up with unbootable
system.
- Panu -
3:16 p.m.
On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote:
On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
> Again, show me how kmdl scales. A university/enterprise environment is
> not a 3rd party extras repository.
I pointed out earlier in this thread that we've used a scheme similar to
kmdl at work (speaking of thousands of systems here) rather successfully
for several years. And like I stated previously as well, this is just
for the record, I'm not arguing for either scheme.
It's not kmdl or kmod that scales, it's the processes for releasing
kernel modules and the depsolver+plugin to handle them which need to
"scale": a plugin can be smart enough to skip the kernel update if no
corresponding kernel module for the new version can be found, or abort
the entire update. But you'll need plugins for both schemes to catch the
situation where somehow a new kernel slipped out without having kernel
modules for it available, otherwise you can end up with unbootable
system.
monkey-wrench question:
what happens if both versions of a kernel module work on the available
kernel but work with different versions of the userland tools?
-sv
3:34 p.m.
On Mon, 2006-08-14 at 16:16 -0400, seth vidal wrote:
On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote:
> On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
>
> > Again, show me how kmdl scales. A university/enterprise environment is
> > not a 3rd party extras repository.
>
> I pointed out earlier in this thread that we've used a scheme similar to
> kmdl at work (speaking of thousands of systems here) rather successfully
> for several years. And like I stated previously as well, this is just
> for the record, I'm not arguing for either scheme.
>
> It's not kmdl or kmod that scales, it's the processes for releasing
> kernel modules and the depsolver+plugin to handle them which need to
> "scale": a plugin can be smart enough to skip the kernel update if no
> corresponding kernel module for the new version can be found, or abort
> the entire update. But you'll need plugins for both schemes to catch the
> situation where somehow a new kernel slipped out without having kernel
> modules for it available, otherwise you can end up with unbootable
> system.
>
monkey-wrench question:
what happens if both versions of a kernel module work on the available
kernel but work with different versions of the userland tools?
S**t hits the fan, that's what happens... and neither scheme can protect
against that. Similar things can happen with the main kernel itself..
you can update the kernel along with a userland (hal, udev or such)
package which is incompatible with the running kernel yet rpm
dependencies are satisfied.
Runtime dependencies/provides would help a bit but then you'd have
unresolvable deps on all the non-running kernels -> doesn't work either.
- Panu -
3:36 p.m.
On Monday 14 August 2006 16:16, seth vidal wrote:
monkey-wrench question:
what happens if both versions of a kernel module work on the available
kernel but work with different versions of the userland tools?
Heee! You gotta go and make it difficult don't you... (:
I haven't the brain bandwidth to think on this issue currently. Lets just try
to Not Do This, as it hurts when I poke myself in the eyeball w/ my pen.
--
Jesse Keating
Release Engineer: Fedora
3:37 p.m.
On Mon, Aug 14, 2006 at 04:36:41PM -0400, Jesse Keating wrote:
On Monday 14 August 2006 16:16, seth vidal wrote:
> monkey-wrench question:
>
> what happens if both versions of a kernel module work on the available
> kernel but work with different versions of the userland tools?
Heee! You gotta go and make it difficult don't you... (:
I haven't the brain bandwidth to think on this issue currently. Lets just try
to Not Do This, as it hurts when I poke myself in the eyeball w/ my pen.
--
Jesse Keating
Release Engineer: Fedora
Is it worth documenting this in the guidelines?
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
6:04 p.m.
On Mon, Aug 14, 2006 at 04:16:22PM -0400, seth vidal wrote:
On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote:
> On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
>
> > Again, show me how kmdl scales. A university/enterprise environment is
> > not a 3rd party extras repository.
>
> I pointed out earlier in this thread that we've used a scheme similar to
> kmdl at work (speaking of thousands of systems here) rather successfully
> for several years. And like I stated previously as well, this is just
> for the record, I'm not arguing for either scheme.
>
> It's not kmdl or kmod that scales, it's the processes for releasing
> kernel modules and the depsolver+plugin to handle them which need to
> "scale": a plugin can be smart enough to skip the kernel update if no
> corresponding kernel module for the new version can be found, or abort
> the entire update. But you'll need plugins for both schemes to catch the
> situation where somehow a new kernel slipped out without having kernel
> modules for it available, otherwise you can end up with unbootable
> system.
>
monkey-wrench question:
what happens if both versions of a kernel module work on the available
kernel but work with different versions of the userland tools?
Can you explain? Do you mean two subsequent package versions of a
kernel module, e.g. a version bump in the module's versioning side?
--
Axel.Thimm at ATrpms.net
3:30 p.m.
On Mon, Aug 14, 2006 at 11:11:46PM +0300, Panu Matilainen wrote:
On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
> Again, show me how kmdl scales. A university/enterprise environment is
> not a 3rd party extras repository.
I pointed out earlier in this thread that we've used a scheme similar to
kmdl at work (speaking of thousands of systems here) rather successfully
for several years. And like I stated previously as well, this is just
for the record, I'm not arguing for either scheme.
It's not kmdl or kmod that scales, it's the processes for releasing
kernel modules and the depsolver+plugin to handle them which need to
"scale": a plugin can be smart enough to skip the kernel update if no
corresponding kernel module for the new version can be found, or abort
the entire update. But you'll need plugins for both schemes to catch the
situation where somehow a new kernel slipped out without having kernel
modules for it available, otherwise you can end up with unbootable
system.
- Panu -
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
Panu,
I can agree with this. Can you point out some working code?
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
3:55 p.m.
On Mon, 2006-08-14 at 16:30 -0400, Jack Neely wrote:
On Mon, Aug 14, 2006 at 11:11:46PM +0300, Panu Matilainen wrote:
> On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote:
>
> > Again, show me how kmdl scales. A university/enterprise environment is
> > not a 3rd party extras repository.
>
> I pointed out earlier in this thread that we've used a scheme similar to
> kmdl at work (speaking of thousands of systems here) rather successfully
> for several years. And like I stated previously as well, this is just
> for the record, I'm not arguing for either scheme.
>
> It's not kmdl or kmod that scales, it's the processes for releasing
> kernel modules and the depsolver+plugin to handle them which need to
> "scale": a plugin can be smart enough to skip the kernel update if no
> corresponding kernel module for the new version can be found, or abort
> the entire update. But you'll need plugins for both schemes to catch the
> situation where somehow a new kernel slipped out without having kernel
> modules for it available, otherwise you can end up with unbootable
> system.
>
Panu,
I can agree with this. Can you point out some working code?
The kernel-module plugin for apt in FE does something like that (it'll
warn you in the above situation, could be made to block the update of
course), but it only works with old fedora.us/livna.org style
kernel-module-foo-`uname -r` packages, IIRC would need some tweaking for
kmdl. I haven't bothered updating my plugins for any new schemes as I've
waited for this very battle to sort itself out some day :)
- Panu -
6:08 p.m.
On Mon, Aug 14, 2006 at 11:11:46PM +0300, Panu Matilainen wrote:
But you'll need plugins for both schemes to catch the situation
where somehow a new kernel slipped out without having kernel modules
for it available, otherwise you can end up with unbootable system.
The kmdl plugin has two modes that cover that:
o yum install: Only triggers kmdl coinstallation if a kernel will be
installed in this transactions and only for this kernel
o yum update: Check for new available kmdls for already installed
kernels
kmdls will by definition - be it a 3rd party or an ISV/ISH - be shipped
delayed. Maybe not for RHEL where selected partners get early access
to final bits to prepare their add-ons, but certainly for non-premioum
partners and for all Fedora land.
Therefore any plugin needs to be able to asyncronously fill the
gaps.
--
Axel.Thimm at ATrpms.net
2:54 p.m.
On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
> a) kernel module scheme needs uname-r-in-name
+/-0 currently if we only work for Fedora here.
-1 currently if we want the same stuff in RHEL and Fedora -- the "uname
-r" is not that important with the kabi stuff and the problem should be
fixed properly.
Note the word "currently".
> b) kernel module scheme needs one-specfile approach (for both usreland
> and kernel modules)
-1 ; Reasons:
- changes only in the kmod will require that the userland packages gets
rebuild, too. That unnecessary. Yes, it can be prevented manually. But
we would have to make sure that SRPMs for the old userland packages stay
in the repo; and we would need special handling in the buildsys -> can
of worms.
- people during the last kmod development didn't like having spec files
with a lot of
--
%if userland
do stuff to build userland
#endif
%if module
do stuff to build kmod
#endif
- Because the name of the SRPM doesn't change when you rebuild stuff for
a newly released kernel the name of the debuginfo packages does also not
change. So with a one-specfile approach we'd have to
-- created manually; we tried that during the development of the kmod
standard. We didn't like it
or
-- that the release in increased everytime so the new debuginfo packages
gets a new name -- creates the SRPMS problem described above
> c) kernel module scheme needs to be kernel agnostic (both version
> *and* flavour)
+1 -- They are agnostic already. The current hardwiring in the spec file
is only a temporary solution until we have proper support in the
buildsys. Yes, there is one place in "kmodtool" where the flavours are
hardcoded for users that rebuild kmods manually to prevent that they do
something wrong.
> d) support for coinstallation of kmdls should be pushed into FC6 asap
> (working plugin has already been submitted here and tested be
> ATrpms users). Requires a positive vote on a-c)
-1 -- we took about half a year to develop the current standard for FE.
I'm not going to switch to something where besides Axel no one of the
people around has practical experiences
- in a hurry
- without getting a buy-in from Jeremy, f13, davej, warren and jcmasters
- after test2
- shortly before RHEL beta 1 (or is it out already?)
I'd even tend to say: We shouldn't change what was discussed below
"a)"
(see above) at this point. To risky IMHO.
> e) [...] Requires a positive vote on a-d) [...]
I had to many -1 up to here, so I'm stopping now ;-)
CU
thl
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
I'm with Thorsten.
-1
*) We are way too late to implement a completely new kernel module for
FE6/FC6 and RHEL 5. We were on schedule with the kmod scheme. But
alas, I've not coded more things because I've been practicing my email
skills. (Site point d)
*) I also site the scalability concerns.
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
12:19 p.m.
On Friday 11 August 2006 06:58, Axel Thimm wrote:
I suggest to vote through email about replacing the current kernel
scheme with the kmdl or similar scheme.
Perhaps I'm dumb, but after reading your wiki page I'm still not seeing where
the current scheme really falls over. We have kmod packages treated like
kernel packages in that they are install rather than upgrade. This is the
same way that the kernel is handled, and if people do silly things with the
rpm command line they can break their kernel just as easily as they can break
their kernel modules. We have this handling in yum, which is the basis of
every depsolver we support in Fedora / Red Hat. Yum is used by pup, puplet,
pirut, and anaconda. All of these make use of the special casing we have in
Yum and handle kmods correctly by installing rather than upgrading them. If
other depsolvers don't, well that's really too bad and its up to those
depsolvers to handle the packages correctly like they (should) handle kernel
packages correctly.
So, I guess I'm being dumb, and I need it spelled out in big foam letters as
I'm just not getting it, and thus I can't vote on it.
--
Jesse Keating
Release Engineer: Fedora
1:16 p.m.
On Mon, Aug 14, 2006 at 01:19:32PM -0400, Jesse Keating wrote:
On Friday 11 August 2006 06:58, Axel Thimm wrote:
> I suggest to vote through email about replacing the current kernel
> scheme with the kmdl or similar scheme.
Perhaps I'm dumb, but after reading your wiki page I'm still not seeing where
the current scheme really falls over. We have kmod packages treated like
kernel packages in that they are install rather than upgrade. This is the
same way that the kernel is handled, and if people do silly things with the
rpm command line they can break their kernel just as easily as they can break
their kernel modules.
No, the issue is that kernel modules packages are neither to be
"coinstalled", nor to be "upgraded" if the package entity is not
disambiguated w/ uname-r-in-name
I've give such an exmaple before, try writing down an rpm command for
the following situation:
Installed:
kernel-a
module-2-for-a
kernel-b
module-1-for-b
Now try to install module-2-for-b. For kmdls it's just rpm -U. For
kmods it's impossible, you need to coinstall with module-2-for-a but
upgrade module-1-for-b.
That's why every depsolver suddenly needs a plugin to do anything at
all with kmods. The plugin needs to take this awkward situation in
account and undo things that yum considered sane to do (but yum was
only following rpm logic).
But the argument goes on that once you pull in a package "by mistake"
you cannot undo it unless it is trivial e.g. has no further package
depedencies like requires/obsoletes/conflict. These cascade further
changes in yum's dependency resolver and undoing them in a plugin
effectivly lead to redesigning yum in the plugin.
Currently the plugin assumes that is not the case, which is the case
with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will
fail in these cases.
And any plugin for any other depsolver will fail the same and rpm
doesn't have plugins. The net result is a half-working yum, borken
rpm, broken smart etc.
In comtrast if the scheme respects rpm rules like the kmdl scheme does
you don't need to undo yum's work, just add the coinstall support. It
turns out that the plugin for kmdls was less than half the current
plugin for kmods which performs less and is still broken as outlined
above.
We have this handling in yum, which is the basis of every depsolver
we support in Fedora / Red Hat. Yum is used by pup, puplet, pirut,
and anaconda. All of these make use of the special casing we have
in Yum and handle kmods correctly by installing rather than
upgrading them.
Thanks for the list. This means all of them are currently broken as
outlined. And all of them can be fixed by following basic rpm rules
like the kmdls do. The key point here is uname-r-in-name.
If other depsolvers don't, well that's really too bad and its
up to
those depsolvers to handle the packages correctly like they (should)
handle kernel packages correctly.
I agree, if rpm and yum/pup/etc *could* deal with it, but they don't.
So, I guess I'm being dumb, and I need it spelled out in big
foam
letters as I'm just not getting it, and thus I can't vote on it.
Is the example above & argumentation clear? If yes, and the wiki is
not please suggest where to inject an example or soem more working in
the wiki.
--
Axel.Thimm at ATrpms.net
1:31 p.m.
On Monday 14 August 2006 14:16, Axel Thimm wrote:
No, the issue is that kernel modules packages are neither to be
"coinstalled", nor to be "upgraded" if the package entity is not
disambiguated w/ uname-r-in-name
I've give such an exmaple before, try writing down an rpm command for
the following situation:
Installed:
kernel-a
module-2-for-a
kernel-b
module-1-for-b
Now try to install module-2-for-b. For kmdls it's just rpm -U. For
kmods it's impossible, you need to coinstall with module-2-for-a but
upgrade module-1-for-b.
That's why every depsolver suddenly needs a plugin to do anything at
all with kmods. The plugin needs to take this awkward situation in
account and undo things that yum considered sane to do (but yum was
only following rpm logic).
Seems to me that we're really trying to beat around a deficiency in RPM.
Creating whole new packages for every single kernel release is insane. New
cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our
entire infrastructure is based around the name of a package. Changing that
for every single kernel update, or special casing it in every system is just
silly. REALLY silly. I will absolutely vote against it.
But the argument goes on that once you pull in a package "by
mistake"
you cannot undo it unless it is trivial e.g. has no further package
depedencies like requires/obsoletes/conflict. These cascade further
changes in yum's dependency resolver and undoing them in a plugin
effectivly lead to redesigning yum in the plugin.
Currently the plugin assumes that is not the case, which is the case
with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will
fail in these cases.
I have read these two paragraphs 5 times, and I still don't understand what
you are saying. Examples work wonders. I'm lost in hyperbole land.
And any plugin for any other depsolver will fail the same and rpm
doesn't have plugins. The net result is a half-working yum, borken
rpm, broken smart etc.
In comtrast if the scheme respects rpm rules like the kmdl scheme does
you don't need to undo yum's work, just add the coinstall support. It
turns out that the plugin for kmdls was less than half the current
plugin for kmods which performs less and is still broken as outlined
above.
You're working around an issue in rpm by creating new packages all the time.
That's not a solution, that's an ugly hack.
> We have this handling in yum, which is the basis of every
depsolver
> we support in Fedora / Red Hat. Yum is used by pup, puplet, pirut,
> and anaconda. All of these make use of the special casing we have
> in Yum and handle kmods correctly by installing rather than
> upgrading them.
Thanks for the list. This means all of them are currently broken as
outlined. And all of them can be fixed by following basic rpm rules
like the kmdls do. The key point here is uname-r-in-name.
Or, instead of introducing the insanity of uname-r in name, we can put effort
into adjusting rpm and yum to handle this sort of package situation
correctly.
> If other depsolvers don't, well that's really too bad
and its up to
> those depsolvers to handle the packages correctly like they (should)
> handle kernel packages correctly.
I agree, if rpm and yum/pup/etc *could* deal with it, but they don't.
> So, I guess I'm being dumb, and I need it spelled out in big foam
> letters as I'm just not getting it, and thus I can't vote on it.
Is the example above & argumentation clear? If yes, and the wiki is
not please suggest where to inject an example or soem more working in
the wiki.
Thanks, I've heard enough to make up my mind. -1 on the entire thing.
--
Jesse Keating
Release Engineer: Fedora
1:41 p.m.
On Mon, 2006-08-14 at 14:31 -0400, Jesse Keating wrote:
On Monday 14 August 2006 14:16, Axel Thimm wrote:
> No, the issue is that kernel modules packages are neither to be
> "coinstalled", nor to be "upgraded" if the package entity is
not
> disambiguated w/ uname-r-in-name
>
> I've give such an exmaple before, try writing down an rpm command for
> the following situation:
>
> Installed:
>
> kernel-a
> module-2-for-a
>
> kernel-b
> module-1-for-b
>
> Now try to install module-2-for-b. For kmdls it's just rpm -U. For
> kmods it's impossible, you need to coinstall with module-2-for-a but
> upgrade module-1-for-b.
>
> That's why every depsolver suddenly needs a plugin to do anything at
> all with kmods. The plugin needs to take this awkward situation in
> account and undo things that yum considered sane to do (but yum was
> only following rpm logic).
Seems to me that we're really trying to beat around a deficiency in RPM.
Creating whole new packages for every single kernel release is insane. New
cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our
entire infrastructure is based around the name of a package. Changing that
for every single kernel update, or special casing it in every system is just
silly. REALLY silly. I will absolutely vote against it.
The entire infrastructure is based around the name of the SOURCE package
which remains the same with kmdls just like with kmods, normal
subpackage splits etc.
- Panu -
1:54 p.m.
On Monday 14 August 2006 14:41, Panu Matilainen wrote:
The entire infrastructure is based around the name of the SOURCE
package
which remains the same with kmdls just like with kmods, normal
subpackage splits etc.
Hrm, ok, so less impact on infrastructure. Its still a package that changes
its name potentially with every rebuild which is still no good in my book.
ESPECIALLY as a hack to work around other issues.
--
Jesse Keating
Release Engineer: Fedora
2:17 p.m.
On Mon, 2006-08-14 at 14:54 -0400, Jesse Keating wrote:
On Monday 14 August 2006 14:41, Panu Matilainen wrote:
> The entire infrastructure is based around the name of the SOURCE package
> which remains the same with kmdls just like with kmods, normal
> subpackage splits etc.
Hrm, ok, so less impact on infrastructure. Its still a package that changes
its name potentially with every rebuild which is still no good in my book.
ESPECIALLY as a hack to work around other issues.
It's not much worse than openssl :D
Seriously, yes the changing package names are a a bit of a pain, silly
things like scripts to prune out old packages from a repo suddenly need
to be aware of version-in-name thing as well etc.
Both schemes have their good points and weak points and both have been
shown to work most of the time in real world, that's why I suggested
flipping a coin over it earlier in this thread...
- Panu -
2:15 p.m.
>>>> "JK" == Jesse Keating
<jkeating(a)redhat.com> writes:
JK> Or, instead of introducing the insanity of uname-r in name, we can
JK> put effort into adjusting rpm and yum to handle this sort of
JK> package situation correctly.
It seems like what we really need is some sort of two-dimensional
versioning. I guess everyone will just laugh at me for suggesting it,
but for a plugin/module "foo" having version "M" which works with
"packageA" version "N", just call it
"packageA-module-foo-M,N", teach
the depsolvers how to deal with it, and get on with life.
- J<
2:18 p.m.
Jason L Tibbitts III wrote:
>>>>> "JK" == Jesse Keating
<jkeating(a)redhat.com> writes:
JK> Or, instead of introducing the insanity of uname-r in name, we can
JK> put effort into adjusting rpm and yum to handle this sort of
JK> package situation correctly.
It seems like what we really need is some sort of two-dimensional
versioning. I guess everyone will just laugh at me for suggesting it,
but for a plugin/module "foo" having version "M" which works with
"packageA" version "N", just call it
"packageA-module-foo-M,N", teach
the depsolvers how to deal with it, and get on with life.
It may be just me, but I would categorize the latter effort closer to
insanity than the former.
-- Rex
6:31 p.m.
On Mon, Aug 14, 2006 at 02:15:59PM -0500, Jason L Tibbitts III wrote:
>>>>> "JK" == Jesse Keating
<jkeating(a)redhat.com> writes:
JK> Or, instead of introducing the insanity of uname-r in name, we can
JK> put effort into adjusting rpm and yum to handle this sort of
JK> package situation correctly.
It seems like what we really need is some sort of two-dimensional
versioning. I guess everyone will just laugh at me for suggesting it,
I'm not, that's exactly the issue here.
but for a plugin/module "foo" having version "M"
which works with
"packageA" version "N", just call it
"packageA-module-foo-M,N", teach
the depsolvers how to deal with it, and get on with life.
That can take half a decade, so we should find a solution for now and
lobby with our experiences for rpmng's design.
This is off-topic, but I really thing that at some time in the future
our group could start thinking about setting up specifications for a
new package manager trying to learn from rpm's deficiencies and trying
to unearth a project for that.
--
Axel.Thimm at ATrpms.net
7:35 p.m.
On Mon, Aug 14, 2006 at 02:31:41PM -0400, Jesse Keating wrote:
Seems to me that we're really trying to beat around a deficiency
in RPM.
Yes, that's pinned down nicely by tibbs as making rpm
two-dimensional. But that's what we've got and it is not going to
change for a long time.
Creating whole new packages for every single kernel release is
insane. New
cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our
entire infrastructure is based around the name of a package. Changing that
for every single kernel update, or special casing it in every system is just
silly. REALLY silly. I will absolutely vote against it.
As outlined by Panu this is not the case. In fact the infrastructure
and maintenance is halfed as there is really only one name, not two
like it is today. The kmod standard need two bugzilla entries per
package, two owner entries, two cvs modules. kmdls only need one.
So may I take that as a vote in favour of a one-sepcfile design? :)
> But the argument goes on that once you pull in a package
"by mistake"
> you cannot undo it unless it is trivial e.g. has no further package
> depedencies like requires/obsoletes/conflict. These cascade further
> changes in yum's dependency resolver and undoing them in a plugin
> effectivly lead to redesigning yum in the plugin.
>
> Currently the plugin assumes that is not the case, which is the case
> with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will
> fail in these cases.
I have read these two paragraphs 5 times, and I still don't understand what
you are saying. Examples work wonders. I'm lost in hyperbole land.
OK, suppose some kernel module scheme like kmod works against yum's
depsolving. Since yum adhears to rpm orderign and the kmod scheme
doesn't that's not difficult to achive.
Now the setup is such that yum will either install too many or to few
packages. Too few is good, you can always add to yum's transaction and
yum will compute the new dependencies. Too much is really bad, because
the pulled in packages will pull in more packages or push out others
(due to Requires/Obsoletes/Conflicts).
Let's get to an example:
ipw3945 version X (the exmaple is real, but don't have me lookup the
true versions please) requires ipw3945d Y (a userland daemon). ipw3945
X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X
this will have pulled in ipw3945d-Y. Undoing this in some plugin code
would only remove ipw3945-X, not ipw3945d-Y.
Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc.
You're working around an issue in rpm by creating new packages
all the time.
That's not a solution, that's an ugly hack.
The packages are really distinct and have different functionality and
depednencies. You need both evrs in the total package filename. Moving
them to the rpm name turns to solve 95% of all issues. And the fears
on increased infrastructure are unbased, you even save some.
Thanks, I've heard enough to make up my mind. -1 on the entire
thing.
OK, is that still the case after having seen that infrastructure is
not bitten?
--
Axel.Thimm at ATrpms.net
8:02 p.m.
On Monday 14 August 2006 20:35, Axel Thimm wrote:
As outlined by Panu this is not the case. In fact the infrastructure
and maintenance is halfed as there is really only one name, not two
like it is today. The kmod standard need two bugzilla entries per
package, two owner entries, two cvs modules. kmdls only need one.
So may I take that as a vote in favour of a one-sepcfile design? :)
Absolutely not. Userland is separate from the kernel module. Forcing the
userland crud to be rebuilt and reshipped and redownloaded each and every
time the kernel is updated (or kabi changes) is ridiculous. There is a big
difference between a set of userland+kmod for each module set and a new
package each and every time the kernel is updated.
> > But the argument goes on that once you pull in a package
"by mistake"
> > you cannot undo it unless it is trivial e.g. has no further package
> > depedencies like requires/obsoletes/conflict. These cascade further
> > changes in yum's dependency resolver and undoing them in a plugin
> > effectivly lead to redesigning yum in the plugin.
> >
> > Currently the plugin assumes that is not the case, which is the case
> > with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will
> > fail in these cases.
>
> I have read these two paragraphs 5 times, and I still don't understand
> what you are saying. Examples work wonders. I'm lost in hyperbole land.
OK, suppose some kernel module scheme like kmod works against yum's
depsolving. Since yum adhears to rpm orderign and the kmod scheme
doesn't that's not difficult to achive.
Now the setup is such that yum will either install too many or to few
packages. Too few is good, you can always add to yum's transaction and
yum will compute the new dependencies. Too much is really bad, because
the pulled in packages will pull in more packages or push out others
(due to Requires/Obsoletes/Conflicts).
Let's get to an example:
ipw3945 version X (the exmaple is real, but don't have me lookup the
true versions please) requires ipw3945d Y (a userland daemon). ipw3945
X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X
this will have pulled in ipw3945d-Y. Undoing this in some plugin code
would only remove ipw3945-X, not ipw3945d-Y.
Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc.
Are you really going to versionize the entire userland? Have a separate
daemon for each possible module version? How does THAT work at boot time?
When your userland moves beyond what your kernel can handle (udev updates,
etc..) perhaps its time to update your kernel. If you can't, well then
perhaps you shouldn't be using a distribution that moves quickly. And if
you're changing the userland that fast on a RHEL product, well then you're
using it wrong and tough ditty.
> You're working around an issue in rpm by creating new
packages all the
> time. That's not a solution, that's an ugly hack.
The packages are really distinct and have different functionality and
depednencies. You need both evrs in the total package filename. Moving
them to the rpm name turns to solve 95% of all issues. And the fears
on increased infrastructure are unbased, you even save some.
> Thanks, I've heard enough to make up my mind. -1 on the entire thing.
OK, is that still the case after having seen that infrastructure is
not bitten?
Nope. The infrastructure bits were only a small part of my concern. Still
a -1.
--
Jesse Keating
Release Engineer: Fedora
8:26 p.m.
On Mon, Aug 14, 2006 at 09:02:01PM -0400, Jesse Keating wrote:
On Monday 14 August 2006 20:35, Axel Thimm wrote:
> As outlined by Panu this is not the case. In fact the infrastructure
> and maintenance is halfed as there is really only one name, not two
> like it is today. The kmod standard need two bugzilla entries per
> package, two owner entries, two cvs modules. kmdls only need one.
>
> So may I take that as a vote in favour of a one-sepcfile design? :)
Absolutely not. Userland is separate from the kernel module.
Forcing the userland crud to be rebuilt and reshipped and
redownloaded each and every time the kernel is updated (or kabi
changes) is ridiculous. There is a big difference between a set of
userland+kmod for each module set and a new package each and every
time the kernel is updated.
Yes, I agree, so it's nice that this is not the case with kmdls :)
Just go over to ATrpms and have a look at the packages. You have many
misunderstandings on the kmdl proposal and maybe looking at real
packages may help. Testing them out with the kmdl plugin would be even
better.
> Let's get to an example:
>
> ipw3945 version X (the exmaple is real, but don't have me lookup the
> true versions please) requires ipw3945d Y (a userland daemon). ipw3945
> X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X
> this will have pulled in ipw3945d-Y. Undoing this in some plugin code
> would only remove ipw3945-X, not ipw3945d-Y.
>
> Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc.
Are you really going to versionize the entire userland?
No, the versions above are not kernel versions, you misinterpreted
them. The example is all within the same kernel, say 2.6.17-Z if you like.
Have a separate daemon for each possible module version?
Again a misinterpretation. The daemon has nothing to do with the kmdl
scheme, it's part of the project. There is no daemon in the
design. But you asked for real life examples and that is one. Instead
of a daemon this might be the firmware packages etc, and no - the
kmdls scheme doesn't need firmwares per module, neither. :)
How does THAT work at boot time? When your userland moves beyond
what your kernel can handle (udev updates, etc..) perhaps its time
to update your kernel. If you can't, well then perhaps you
shouldn't be using a distribution that moves quickly. And if you're
changing the userland that fast on a RHEL product, well then you're
using it wrong and tough ditty.
All in the wrong context, you made some wrong assumptions and ended in
a devastating picture of the kmdl scheme. I shudder myself from such a
vision. :)
> > Thanks, I've heard enough to make up my mind. -1 on
the entire thing.
Nope. The infrastructure bits were only a small part of my concern. Still
a -1.
You are misinterpreting my explanations beyond recognition, so perhaps
I should simply accept that. ;) If doubts come up, you know where to
find me.
It's 2 in favour 1 against for now. Still looking for 4 people which
will give their +1. :)
--
Axel.Thimm at ATrpms.net
12:42 a.m.
New subject: Proposal: reject the one-spec approach (was: Re: Mail voting on kmdl adoption)
Hi all!
I think we fight to many battles at once. So let's start concentrate on
one of the easy ones first. As the uname -r debatte is likely to take
some time I choose the "one-spec approach" one.
I'd like to propose that the packaging group rejects this part from
Axels scheme:
Axel Thimm schrieb:
b) kernel module scheme needs one-specfile approach (for both usreland
and kernel modules)
We currently have a split with the current kmod standard, e.g. userland
and kmod have their own packages (spot was one of the drivers behind it
IIRC).
Both approaches have small advantages and disadvantages (I don't think
mention the pros and cons of each one here makes much sense), but there
is nothing earth scattering that make one of the two much better.
But the split
- was agreed on some month ago by FESCo (the predecessor of the
packaging committee in this respect). Why change it again without a good
reason?
- changeing all the existing specs over to a one-specfile approach will
be a lot of work because
-- it's already in production (in FE and LVN)
-- we have a lot of packages under review that use the split approach;
-- is time critical because we're already after test2
- packagers and some reviewers are familiar with it already
- it works in the buildsystem already -- the kmdl scheme would need
special handling that needs to be programmed
So changing this will be lot's of trouble without a benefit. So let's
reject this part now.
CU
thl
3:20 a.m.
New subject: Proposal: reject the one-spec approach (was: Re: Mail voting on kmdl adoption)
On Tue, Aug 15, 2006 at 07:42:53AM +0200, Thorsten Leemhuis wrote:
I think we fight to many battles at once. So let's start
concentrate on
one of the easy ones first. As the uname -r debatte is likely to take
some time I choose the "one-spec approach" one.
-- it's already in production (in FE and LVN)
-- we have a lot of packages under review that use the split approach;
There is exactly one (1) package in Fedora and lives only in FE5.
-- is time critical because we're already after test2
For this very one package ...
- packagers and some reviewers are familiar with it already
I only count Ville and you.
- it works in the buildsystem already -- the kmdl scheme would need
special handling that needs to be programmed
In a previous mail you admitted not being kernel agnostic yet because
otherwise your kmods won't build. And I offered adding kmdl support to
the buildsystem.
So changing this will be lot's of trouble without a benefit. So
let's
reject this part now.
No, please don't listen to the devil. :)
Thorsten, this is part of the voting, it will be voted upon, if you
allow people to do so. This guerilla tactics are becoming ugly.
--
Axel.Thimm at ATrpms.net
3:38 a.m.
New subject: Proposal: reject the one-spec approach
Axel Thimm schrieb:
On Tue, Aug 15, 2006 at 07:42:53AM +0200, Thorsten Leemhuis wrote:
> I think we fight to many battles at once. So let's start concentrate on
> one of the easy ones first. As the uname -r debatte is likely to take
> some time I choose the "one-spec approach" one.
> -- it's already in production (in FE and LVN)
> -- we have a lot of packages under review that use the split approach;
There is exactly one (1) package in Fedora and lives only in FE5.
+2 more in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod)
+7 under review
+6 in lvn
> -- is time critical because we're already after test2
For this very one package ...
It's to late for FC6 and RHEL IMHO.
> - packagers and some reviewers are familiar with it already
I only count Ville and you.
7 packages under review (from different people afaics), jcmasters,
nirik, f13, jeremy, tibbs
> - it works in the buildsystem already -- the kmdl scheme would
need
> special handling that needs to be programmed
In a previous mail you admitted not being kernel agnostic yet because
otherwise your kmods won't build.
The hardcoded stuff it optional and it works *now*.
> So changing this will be lot's of trouble without a benefit.
So let's
> reject this part now.
No, please don't listen to the devil. :)
:)
Thorsten, this is part of the voting, it will be voted upon, if you
allow people to do so.
Sure.
This guerilla tactics are becoming ugly.
That's why I think it's time that spot as leader of this group IMHO
jumps in. Otherwise we waste a lot of time arguing without results.
CU
thl
3:43 a.m.
New subject: Proposal: reject the one-spec approach
On Tue, Aug 15, 2006 at 10:38:46AM +0200, Thorsten Leemhuis wrote:
>There is exactly one (1) package in Fedora and lives only in
FE5.
+2 more in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod)
+7 under review
+6 in lvn
-67 in ATrpms
Looks like you're raising this to an ATrpms vs livna issue? I thought
we wanted to merge ...
>This guerilla tactics are becoming ugly.
That's why I think it's time that spot as leader of this group IMHO
jumps in. Otherwise we waste a lot of time arguing without results.
When he showed he tends to a uname-r-in-version solution you seem to
have activated all your muscles against it even though you promised
otherwise before.
You still have your chance to reject it in fesco.
--
Axel.Thimm at ATrpms.net
5:16 a.m.
New subject: Proposal: reject the one-spec approach
Axel Thimm schrieb:
On Tue, Aug 15, 2006 at 10:38:46AM +0200, Thorsten Leemhuis wrote:
>> There is exactly one (1) package in Fedora and lives only in FE5.
> +2 more in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod)
> +7 under review
> +6 in lvn
-67 in ATrpms
Looks like you're raising this to an ATrpms vs livna issue? I thought
we wanted to merge ...
I hope we can still merge.
>> This guerilla tactics are becoming ugly.
> That's why I think it's time that spot as leader of this group IMHO
> jumps in. Otherwise we waste a lot of time arguing without results.
When he showed he tends to a uname-r-in-version solution you seem to
have activated all your muscles against it even though you promised
otherwise before.
I activated all my muscles for a complete switch from the current kmod
standard to something else because
- the current kmod standard was developed in half a year with a lot of
work involved from me, scop, jeremy, warren, f13 and others. jcmaster
(and other people I never have heard of) invested a lot of time in it
for RHEL. Throwing that completely away would be painful, but I would do
that if there are good reasons for it. I can't see them.
Question to scop, jeremy, warren, f13, jcmaster: Do you see any reasons
why we should throw away everything?
- throwing it away this short before RHEL beta1 and FC6test3 is IMHO not
acceptable -- especially because we don't have many experiences with it
(well, scop, I and some others have experiences with the "uname -r"
scheme, but at least mine were not as good as yours).
Back to the uname-r-in-version thing: Well, I think the
uname-r-in-version solution is not the best solution. But as I said
earlier in this thread:
"0" (e.g. undecided) currently if we only work for Fedora here. But that
would mean that we change kmodtool to handle it as spot cuggested in the
wiki.
"-1" currently if we want the same stuff in RHEL and Fedora -- the
"uname -r" is not that important with the kabi stuff and the problem
should be fixed properly.
Note the word "currently" and "undecided".
You still have your chance to reject it in fesco.
I'm not doing the FESCo decisions alone.
CU
thl
6:13 a.m.
New subject: Proposal: reject the one-spec approach
Thorsten Leemhuis schrieb:
Axel Thimm schrieb:
> On Tue, Aug 15, 2006 at 10:38:46AM +0200, Thorsten Leemhuis wrote:
>>> This guerilla tactics are becoming ugly.
>> That's why I think it's time that spot as leader of this group IMHO
>> jumps in. Otherwise we waste a lot of time arguing without results.
>
> When he showed he tends to a uname-r-in-version solution you seem to
> have activated all your muscles against it even though you promised
> otherwise before.
I activated all my muscles for
s/for/against/ -- but that's pretty obvious probably ;-)
a complete switch from the current kmod
standard to something else because
[...]
CU
thl
12:44 p.m.
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
I suggest to vote through email [...]
5 voted, 5 still to go. Can the remaining committee members do their
voting business, please? Maybe we get this rejected and all can be
happy again ;)
http://fedoraproject.org/wiki/AxelThimm/kmdls/voting
I added Ville's votes (and copied them verbatim for Toshio on his
wish) but the first because he made it indirectly dependent on the
outcome: Ville & Toshio you need to decide on the first item, if you
are not sure better reject than accept, but don't conditionalize, it
makes vote counting difficult. :)
Note: Don't use "0", it's the same as "-1" in
fedora-packaging.
--
Axel.Thimm at ATrpms.net
9:56 a.m.
On Wed, Aug 16, 2006 at 07:44:31PM +0200, Axel Thimm wrote:
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
> I suggest to vote through email [...]
5 voted, 5 still to go. Can the remaining committee members do their
voting business, please? Maybe we get this rejected and all can be
happy again ;)
http://fedoraproject.org/wiki/AxelThimm/kmdls/voting
I added Ville's votes (and copied them verbatim for Toshio on his
wish) but the first because he made it indirectly dependent on the
outcome: Ville & Toshio you need to decide on the first item, if you
are not sure better reject than accept, but don't conditionalize, it
makes vote counting difficult. :)
Note: Don't use "0", it's the same as "-1" in
fedora-packaging.
As a committee we need to decide on certain items either positive or
negative. Allowing discussion before voting is OK, but having a
stalled voting over weeks isn't really an advertisment for our work.
Please vote within the next day until Wed 16:00UTC. I'll consider the
missing votes as "-1", but mark them as "0" to distinguish from the
actual votes.
--
Axel.Thimm at ATrpms.net
10:31 a.m.
On Tue, 2006-08-22 at 16:56 +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 07:44:31PM +0200, Axel Thimm wrote:
> On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
> > I suggest to vote through email [...]
>
> 5 voted, 5 still to go. Can the remaining committee members do their
> voting business, please? Maybe we get this rejected and all can be
> happy again ;)
>
> http://fedoraproject.org/wiki/AxelThimm/kmdls/voting
>
> I added Ville's votes (and copied them verbatim for Toshio on his
> wish) but the first because he made it indirectly dependent on the
> outcome: Ville & Toshio you need to decide on the first item, if you
> are not sure better reject than accept, but don't conditionalize, it
> makes vote counting difficult. :)
>
> Note: Don't use "0", it's the same as "-1" in
fedora-packaging.
As a committee we need to decide on certain items either positive or
negative. Allowing discussion before voting is OK, but having a
stalled voting over weeks isn't really an advertisment for our work.
Please vote within the next day until Wed 16:00UTC. I'll consider the
missing votes as "-1", but mark them as "0" to distinguish from the
actual votes.
I vote -1 on all items, not because KMDL has anything incorrect, but
because I do not wish to overhaul an existing standard, rather than
correct the flaws present in it.
~spot
--
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
1:49 a.m.
New subject: kmdl voting results (was: Mail voting on kmdl adoption)
On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote:
Hi,
I suggest to vote through email about replacing the current kernel
scheme with the kmdl or similar scheme.
a) kernel module scheme needs uname-r-in-name
b) kernel module scheme needs one-specfile approach (for both usreland
and kernel modules)
c) kernel module scheme needs to be kernel agnostic (both version
*and* flavour)
d) support for coinstallation of kmdls should be pushed into FC6 asap
(working plugin has already been submitted here and tested be
ATrpms users). Requires a positive vote on a-c)
e) Adoption of kmdl interface scheme as used at ATrpms and outlined on
http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive
vote on a-d)
f) Assignment to kmdl-task force to integrate kmdl support into the
buildsystems used by Fedora (myself volunteering). Requires a
positive vote on a-e)
g) Allow kmdl package submissions to Fedora Core/Extras. Requires a
positive vote on a-f)
Without voting, but dependent on vote results: Assist in GFS kmdl
packaging (altready done at FC4 times, needs to resurface).
After a long and painful struggle this matter reached an end. The
voting result is that none of these passes. Also the voting
participation indicates that this is not a topic this committee is
interested in:
http://fedoraproject.org/wiki/AxelThimm/kmdls/voting
Almost half the members of this committee did not care to vote, some
did not even comment on this matter at all. This is a sad thing. Not
for the specific matter (which is sad, too), but because it was an
item one of us worked his ass off to fulfill all possible incoming
requests on documentation, explanation, use cases, examples, synopsis,
whatever, and the least one would expect would be to have more people
vote.
It's ugly to see my efforts being rejected, but being ignored is even
worse.
</whine>
--
Axel.Thimm at ATrpms.net
3:10 p.m.
New subject: kmdl voting results (was: Mail voting on kmdl adoption)
Almost half the members of this committee did not care to vote, some
did not even comment on this matter at all. This is a sad thing. Not
for the specific matter (which is sad, too), but because it was an
item one of us worked his ass off to fulfill all possible incoming
requests on documentation, explanation, use cases, examples, synopsis,
whatever, and the least one would expect would be to have more people
vote.
Indeed. It would have been nice to at least see people who are truly
disinterested vote with a 0. (Note: I am excluding Ralf from this, as
he's said he will be unavailable for the near future)
~spot
6448
days inactive
6461
days old
packaging@lists.fedoraproject.org
64 comments
9 participants
participants (9)
-
Axel Thimm -
Jack Neely -
Jason L Tibbitts III -
Jesse Keating -
Panu Matilainen -
Rex Dieter -
seth vidal -
Thorsten Leemhuis -
Tom Callaway