On Sun, 2006-07-09 at 21:27 +0200, Koen Kooi wrote: > This problem illustrates why I don't like locking down SRCDATEs in > config files; it may work, but was never intended to. I had a discussion > with Richard about SRCDATE, time-limited patches and reproducability on > #oe this afternoon. We still disagree, but we made a compromize and are > going to work from there :) > With the new bitbake, files are cheap so you can split out the common > parts of the kernel recipe into a .inc and make your own snapshot.
As hinted, I take issue with this :). As we can now lock patches to a given time period thanks to a neat idea/implementation by hrw, there is no longer an issue of making a given SCM based .bb file build against a variety of SRCDATES. Why split them into several files which are all effectively the same when a little thought can make it work in one file? Having multiple files means fixes are less likely to propagate all versions as well. Whilst the new cache implementation speeds reparsing unchanged files, the initial parse is still painful and I'd therefore not like to see us adding to that unnecessarily. I understand the issues with distros locking down SRCDATEs. From the general user perspective, its useful to do as things are reproducible, aren't continually rebuilding and most likely to work (patches will apply etc.). We've done this in poky and its one of the features which make it easier to user than OE. Locking down specific dates is also good for distros for reasons of reproducibility. I also realise some people want floating dates and they do mean we react more rapidly to upstream changes. These users are the smallest group and the most able to change things to give floating dates (and fix problems when they appear). > I > still think it's bad form to influence package versions from a > MACHINE.conf and consider that, and the cause a bug. Package versions are a distro option, not machine. In the distro, they can be machine specific and the distros can pool common settings. Richard _______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
