Bug#380089: possibly inadequate solution
On Sun, Jul 30, 2006 at 07:25:20PM -0700, Steve Langasek wrote:
> On Sat, Jul 29, 2006 at 05:53:27PM +0100, martin f krafft wrote:
> > Anyway, I disagree with the way 0.73 fixes the bug: it replicates
> > the functionality provided by mdadm >=2.5-1 into a hack within the
> > package. Granted, the hack is only used when mdadm >=2.5-1 is not
> > installed, but still, it's a hack.
>
> > The maintainer failed to give any reasons why his solution is
> > preferred over a simple conflict against mdadm <<2.5-1, which is
> > what I proposed even before we started the transition. I do not see
> > why we should have a hack ensuring that everything works when mdadm
> > <<2.5-1 is installed, instead of just ensuring that a newer mdadm
> > should be installed by means of a conflict. Then again, a conflict
> > could possibly remove the mdadm package altogether, which would be
> > equally bad. There seems to be no way to tell Debian to conflict
> > with versions prior to a specific package's specific version, but to
> > ensure an upgrade as a resolution conflict, not the package's
> > removal.
>
> Yes, that would be a dependency then, not a conflict. The reasons for not
> making this a dependency are clear.
>
> The reasons for wishing to avoid a versioned Conflicts: are also clear to
> me, being precisely those that you describe above.
indeed aboves thoughts where the primary reason.
also i wanted to stay on the path of a proven solution:
ubuntu had faced the same transition to dapper from breezy, with
prior mdadm without mdadm hooks and they choose to add this small
functionality to mkinitramfs. afaik from their bug tracking system
this worked out. this "duplicate" code will be easily dropped postetch.
> So making initramfs-tools compatible with older versions of mdadm seems like
> a good idea to me. Are there specific reasons why you think the proposed
> solution is technically inadequate?
the implementation itself needs more test,
i had a test sarge upgrade box that weekend where it worked out fine.
mdrun was avoided due too getting random md devices.
although according to fjp older mdadm seems to have it's share
of problems:
http://lists.debian.org/debian-boot/2006/07/msg00244.html
so i hope to stay in contact with madduck to check out
on which range the chosen solution works and refine it.
best regards
--
maks
Reply to: