Re: [libimobiledevice-devel] ipheth

[Paul McEnery <pmcenery@gmail.com>]

On 24 April 2010 08:00, Peter Robinson <pbrobinson@gmail.com> wrote:
> On Sat, Apr 24, 2010 at 6:46 AM, Paul McEnery <pmcenery@gmail.com> wrote:
>> 2010/4/22 Ben Hutchings <ben@decadent.org.uk>:
>>> On Fri, 2010-04-02 at 21:40 +0100, Ben Hutchings wrote:
>>>> On Fri, 2010-04-02 at 21:09 +0100, Paul McEnery wrote:
>>>> [...]
>>>> > 1. Keep the ipheth-utils package and drop ipheth-dkms when ipheth
>>>> > makes it into the mainline kernel. Given that mainline inclusion could
>>>> > take a while, users (of Debian at least) could start to benefit almost
>>>> > immediately since all of the packaging work has already been done.
>>>> [...]
>>>>
>>>> The Debian kernel team's policy on backporting drivers is that drivers
>>>> must have been *accepted* upstream, not that they must have been part of
>>>> an upstream release.  ipheth is a pretty small driver and doesn't appear
>>>> to have any major problems, so I would expect it to be accepted on the
>>>> second submission, within the next week or so.  At that point we can
>>>> immediately add it to our kernel packages.
>>>
>>> Since ipheth has now been accepted by David Miller, I've just added it
>>> to the repository for Debian kernel packages.
>>>
>>
>> Thanks Ben.
>>
>> I'll update the ipheth package in the next couple of days. I'll pick
>> up the discussion about dropping ipheth-dkms on the debian-kernel
>> list...
>
> Was was the final decision of merging the small util into one of the
> other packages and the udev rules into usbmuxd?
>

This was discussed a few weeks ago, but I don't recall anyone being in
overwhelming support of the idea. I'm not sure that usbmuxd should
have *libimobiledevice-utils* as a dependency for something may not be
used by everyone. If there is some value in this, then I think its
worth reopening the discussion.

At this point I'm working on dropping the ipheth-dkms package and
keeping only ipheth-utils which provides the udev rules and pariing
utility.

If the former approach is preferred, then we can look at getting the
respective maintainers involved...

Regards,
Paul.