On Mon, Feb 05, 2007 at 12:04:09PM +0100, Axel Thimm wrote: > On Mon, Feb 05, 2007 at 11:30:17AM +0100, Hans Verkuil wrote: > > > I'm building packages for RHEL and FC as appropriate, they will land > > > in atrpms-testing. > > > > Be aware of the new encoder firmware included with the package! > > I was always packaging v4l-cx2341x-init.mpg, or is there something > else now? > > > > > My intention is to release a ivtv-0.18.0 for kernel 2.6.18, 0.19.0 > > > > for kernel 2.6.19 and a 0.20.0 for kernel 2.6.20. This keeps the > > > > numbering nicely regular. There will probably also be a 0.21.0 for > > > > kernel 2.6.21, > > > > > > If it wouldn't be a too big issue I would recommend using the same > > > versioning throughout all supported kernels. I think it makes the > > > users' handling easier, as well as for people reviewing the code, > > > e.g. it is easier to review some conditionals based on kernel > > > versions than to have several trees. > > > > > > It also makes packaging far more easier, as the userland portions > > > remain in the same versioned subpackage, even if people have both > > > 2.6.18 and 2.6.19 kernels and ivtv kernel subpackages installed.
Makes me wonder, why I'm writing this and forget about it only a couple of days later ... Just to make the case there was a bug at http://bugzilla.atrpms.net/show_bug.cgi?id=1125 that was just about this, a user wanted to have support for both 2.6.18 and 2.6.19 on his system, but the package managers went crazy. Debugging this took both the user and myself some time, only to loop back to this post. So, it's not only for making it easy, but for making it happen at all. Currently the model excludes concurrent installation for support of different kernels, because different kernels require different versions of ivtv and in the case of the userland this overlaps. Even if in reality 0.8.x and 0.9.x userland were exactly the same the conflict would still be there at package level. Would it be possible to have 0.10 build on a range of kernel version w/o coding the target kernel into the versioning? :) > > True, but on the other hand it is much more like what it will be when > > the driver enters the kernel: only limited fixes for older kernels. But > > I'm not yet certain how to handle this. > > Once the driver is in the kernel I wouldn't backport small fixes at > all, I would simply move along with development of a single version > while allowing the software to build for a certain kernel range, > e.g. if certain APIs from 2.6.18 are needed then 2.6.18 upwards. If a > small number of conditionals allow for a broader range of kernel > that's OK (e.g. as long as the pain is small compared to the gain). > > That's the typical model followed by many projects, whether they are > in the kernel already with some version or not, e.g. alsa, ipw*, v4l > etc. It makes talking about features entering the driver easier, > e.g. instead of "super-foo was added to 0.24.5, 0.25.2 and 0.26rc1" > one would just have a single version. > > Having the version stick to the software itself and not correlate with > the kernel version has also other benefits: Once it hits say 2.6.22 as > an internal kernel module it would carry a modversion of > 0.22.0. Perhaps 2.6.23 will see no changes at all, but the users will > be confused about still being on 0.22.0 because they have been > educated to associate the version of the module with that of the > kernel's and also have been warned not to mix. > > And users could check whether their in-kernel or OOT version supports > "super-foo" by the same kernel-independent method, a simple modinfo > ivtv | grep ^version: > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel -- Axel.Thimm at ATrpms.net
pgpo4ci3WXE0Q.pgp
Description: PGP signature
_______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
