Hi Paul, On Tue, 2006-07-11 at 05:03 +0300, Paul Sokolovsky wrote: > Sunday, July 9, 2006, 11:11:45 PM, you wrote: > 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).
In this specific case, the OE file shouldn't need hints from elsewhere to get its internal verison parameters correct. If should probably set the K_MAJOR options itself based on the SRCDATE without outside influence. The concern with your change is that as well as SRCDATE you have to know about the other magic parameters which is far from ideal. > 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. I'm all in favour of this - there are cutting edge kernels for the Zaurus that track the mainline git kernel :) > 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. Nobody is saying otherwise. Its just a question of how to do it. > >> 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? Not in the release tree IMO. The dev branch is where this belong. > 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. You're trying to mix experimental code into a stable branch which is the underlying problem. Either the familar release branch should have (and support) a development distro where these things can be adjusted or the changes should really be being made in dev. The fact dev is perhaps lacking certain key Familiar changes is a different topic. > 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. If you can adapt the kernel .bb file to have knowledge of SRCDATEs and set its variables correctly for the date ranges you need, I don't see a problem. Alternatively, perhaps the kernel SRCDATE in .dev can be updated to a new date. The ipaqs/familiar in dev probably need some TLC anyway and I doubt changing the SRCDATE would see too many objections (but ipaq kernels are not my area of expertise). > 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 All the core OE devs are hackers ;-). There is no objection to what you want, just a question of how we get there. Richard _______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
