Hello Richard, Sunday, July 9, 2006, 11:11:45 PM, you wrote:
> 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. Well, my little knowledge of OE probably doesn't let me track discussion here, but as I wrote in previous mail to Koen, that's exactly the issue I'd like to solve - so OE had means to do arbitrary builds out of the box. handhelds-pxa-2.6_cvs.bb specifically, doesn't allow this, as it is, despite it's name, expects exact hardcoded kernel version from CVS and fail if the version for the requested date has alreday changed (specifically, it will fail on package stage, when it'l fish for modules in /lib/modules/x.y.z). So, my patch just fixes this by using "?=" operators for K_MAJOR and friends assignment. If there's even better way to achieve that, cool, please teach me (and I promise I'll struggle to write a howto on it for novices like me). But even on its own, it does the trick pretty well. And again - it's ok if you don't want machine configs which use that feature in the repo, but please let the people have that tool on the hands for local hacking, I'd say it's very common task to slightly upgrade a package version to get latest hot patches made for device you're currently porting. > 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). Yes, apparently, there cannot be talk about quality of distro unless there's a freeze stage. It's really cool that OE can support these two models with the same metadata! But let's then provide support for both these usages consistently. >> 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. Perfect picture for a perfect world. But how to do about newly ported machines? Would you add my little box to your distro if I just tell that in now boots a kernel? Or if I tell you that to get keys working on it, package X should be upgraded to version Y, would you bump that version for you entire distro (or even add conditionals to a distro config)? Well, so it esentially comes down to 2 questions: 1. As a distro maintainer, would you allow "alpha/beta" devices support? The pros for that are obvious: stuff I did won't be lost if I drop off, plus other users can pick up and work on that too. So, if you do, you'd likely want me to keep my stuff in my own machine file, and don't stain your distro config. 2. If you you rather won't, then, as a framework provider, would you allow me to have easy-to-use and flexible tools tools to work on port locally until it's sufficiently developed? Obviously, I'll prefer to keep device-dependent stuff in a single file, a machine config, as it's imply much easier to track it in one place, plust less strain with contionous mergers. So, again, I don't try to argue on #1 here, but I'd really appreciate your attention to #2 - please try to look from hacker's point of view - I just need those things. Here's a solution, of it there's better, please teach me what it is. More people going to benefit from it. > Richard -- Best regards, Paul mailto:[EMAIL PROTECTED] _______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
