[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#571255: Please fix this



2010/5/12 Marco d'Itri <md@linux.it>:
> On May 12, David Kalnischkies <kalnischkies+debian@gmail.com> wrote:
>
>> It would be really cool if udev could depend on the new kernel - or
> Developers are supposed to know that other packages cannot depend on
> kernel packages.

Good that i am not a developer so i can say crap and ask afterwards
for pointers to a documentation which tells me why udev can't e.g.
Breaks: linux-image-686 (<< x), linux-image-amd64 (<< x), …

Obviously this has blind spots but at least it is defined to work and
doesn't depend on black voodoo. User who haven't these metapackage
installed are the perfect audience for your preinst-fail message
as they will tend to have a self compiled (and specialist) kernels
which they expect to be bootable later on without a message…

>> If udev really can't depend on the kernel i can only think of a note in the
>> Releasenotes and a debconf message displaying a warning if no
>> supported kernel is installed (= the user hasn't followed the Releasenotes).
> This is not enough, udev and the kernel must be installed at the same
> time because the new kernel (indirectly) depends on a newer udev.

As far as i understand i need for a successful boot udev and a kernel without
that option enabled. This doesn't imply to me that i need to install it in
the same dpkg call, not even in the same apt call. Both is pretty hard
to do if you can't express it in the dependencies. I can on the other hand
tell the user that he needs to install other stuff to get the full (or in this
case any) experience later on.
The kernel e.g. does it for some firmware files.

>> This means a lot of people (not following the Releasenotes) will see this
>> warning but doesn't need to do anything about it later as the newer kernel
> This means that every single user will have to manually run apt-get to
> upgrade udev and the kernel, which is annoying and was not needed last
> time we had this issue.

It previously "worked" as udev was optional - now it is important.
I already described why i put quotation marks around "worked" here,
as if we ever depend on that behavior we should have added also
the a-bunch-of-luck package to the dependencies of udev…


Best regards,

David Kalnischkies


Reply to: