[repo-coord] Re: kernel module versioning (was: Blackmailing ...)

[Axel Thimm]

On Thu, May 06, 2004 at 04:34:40PM +0200, Dag Wieers wrote:
> On Thu, 6 May 2004, Axel Thimm wrote:
> > On Thu, May 06, 2004 at 01:25:23PM +0200, bent at biosci.ki.se wrote:
> > > To clueless me it doesn't sound terribly broken....
> > 
> > It isn't. You are confused, because both start with "kernel-module-",
> > but the one Dag promotes has the kernel data in rpm's release tag, not
> > the name tag. This severely breaks any upgrade paths as discussed in
> > these old threads above.
> 
> It doesn't break the upgrade path, and you seem to like 'overstating' 
> things by using wordings like 'breaking severly' etc...

Well, you either get the modules from "ealier" kernels moved away from
your system, or you reply on apt's AllowDuplicates making upgrades
within a kernel impossible. rpm will do the moving the kernel modules
from earlier kernels anyway.

Both scenarios are broken, and if the kernel module in question is
vital the breakage is severe.

> And I do tight the kernel-module naming together with obsoleting uncommon 
> names because they are tight.

Just to get this straight, you define "madwifi" as an uncommon name
for an rpm? Irrespective of the kmdl vs kernel-module string issue,
madwifi-like packages are such containing non-kernel related stuff
(for madwifi there is none, but there is for lirc, nvidia-graphics,
linux-dvb and so on).

So even if/when ATrpms goes kernel-module-something, there will still
be packages like "lirc", "linux-dvb" and so on.

That is certainbly not uncommon.

> Unfortunately Axel calls this blackmailing, I call that common sense.
> 
> I just wished Axel wouldn't be so harsh in these discussions and keep it 
> to the essence. Despite all that I hope we might have a final solution in 
> the making.

Please stop obsoleting other people's repos. You introduced that only
two months ago without any added value to your repo. If it wasn't an
issue to do so back then, it shouldn't be to revert it today, when the
added value would be restoring interrepository compatibility and even
more important having these threads die off.

Once again, please remove the obsoltes. Will you do so?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20040506/c8acdae7/attachment.bin