[Pkg-lirc-maint] [PATCH 0/8] Send in Ubuntu delta in small mergable snippets
s.L-H at gmx.de
Fri Aug 7 20:12:58 UTC 2009
On Friday 07 August 2009, you wrote:
> Hey Stefan:
> On Thu, Aug 6, 2009 at 18:53, Stefan Lippers-Hollmann <s.L-H at gmx.de> wrote:
> > [PATCH 1/8] ???
> > seems to be missing in this patch series?
Thank you, the mailing list doesn't seem to like this mail for some reason
(probably size related).
As it seems this patch does mostly 2 things:
- nuking debconf for lirc-modules-source
this is something I very much agree about
- switching the module buildsystem to dkms
well, dkms has been uploaded to unstable recently and the first modules
are switching over (drbd8-source and optionally openafs-modules-dkms)...
So far I haven't seen a canonical recommendation other than
module-assistant for packaging kernel modules in Debian and given that
the intention is to add lirc-modules-source to linux-modules-extra-2.6,
this switch would be detrimental to that goal (which also requires to
rename lirc-module-source to lirc-source for technical reasons).
This needs further discussion with the other pkg-lirc team members, but
the most I might see here, would be an option like openafs-modules-dkms,
which offers both ways in separate binary source packages.
(on a very personal side note, I do not consider dkms a viable method to
ship kernel modules in Debian, as dpkg knows nothing about it, the
actually built modules are not transferable and, even worse, dkms builds
as root without ever asking the user about it. I for one was pretty angry
to get surprised by drbd8-source suddenly starting to compile on my
system, while I'm very cautious not to risk its integrity by doing
"unsafe" procedures as root - and there've been enough stories of bad
Makefiles replacing /dev/null with a regular file and similar unwanted
side effects. That said, dkms' biggest assets of semi-automatically
adapting to new kernels could be trivially ported to plain
- Vcs-Svn: svn://svn.berlios.de/fullstory/dmakms/trunk
- Vcs-Browser: http://svn.berlios.de/wsvn/fullstory/dmakms/trunk/
but again, this is my very personal opinion)
> > [PATCH 7/8] Source lsb init functions in init script
> > svn r354, additionally adding a dependency on lsb-base
> Great thanks. I'll merge your guy's accepted versions into Ubuntu.
> > [PATCH 8/8] Add udev support to lirc and init script
> > not yet applied, it depends on lirc >= 0.8.4 and further changes
I'll look into this as soon as lirc 0.8.3-4 has hit testing/ squeeze, about
5 days with urgency=medium. I'm not sure yet if 0.8.5 or 0.8.6-pre1 are the
likely target - both will need patching. 0.8.5 for kernel >= 2.6.31,
0.8.6-pre1 to support kernel << 2.6.31.
> > > Having just merged 0.8.5 in Ubuntu and realizing how much of a headache
> > it
> > > was, things need to improve :)
> > This is unfortunately true, especially the debconf handling is an utter
> > mess and needs serious changing and other areas of the packaging aren't in
> > much better shape yet. Unfortunately the kernel modules aren't very likely
> > to go mainline anytime soon either...
> Still got a whole lot of delta on the Ubuntu package, so I'll try to keep
> splitting it up and sending bits in. I was reluctant to keep doing it
> previously until I got some reception by you guys.
Thank you, I really appreciate your efforts and again sorry about my
late response to your last patch series.
> Once we're on a common set of code/packaging, it might be a good idea to
> store the Ubuntu branch on debian svn. I've seen lots of success with this
> in the past with the X team.
Once we have a hal aware lirc version in svn, this is likely to be
relatively easy to accomplish. DKMS might be a little problem, but can
probably be worked around in the packaging.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the Pkg-lirc-maint