-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Sokolovsky schreef: > 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.
That's what branches are for, your machine can work happily in .dev without needing hacks to influence PV from your MACHINE.conf, but will need those to fit into a locked down release branch. > 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. Again, .dev allows you to work on your port and doesn't need those hacks. Furthermore there are guidelines where to keep stuff, which you need to follow if you want your work merged upstream. > 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. Right. Let's stop here for a moment. Let's for a moment pretend you only work against .dev and have no knowledge of branches or rip-offs: Suddenly everything with floating SRCDATE matches the latest state of their upstream repo and you don't need hacks, everything works as-is. So, right now you want to add 'flexibility' *only* because you're trying to retro-fit your port to the now ancient version of OE that familiar is trying to use. Those hacks aren't needed in proper OE, and never will be. So please stop thinking from the mindset of working with an old copy of OE, and start thinking from a fresh .dev perspective. regards, KOen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEs0XgMkyGM64RGpERAoT3AKCSG/v5MLIX1ikkXNRb4L7udEgcigCeIi/s AgLixo3gLVWxy3gov0ocPTI= =gT2J -----END PGP SIGNATURE----- _______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
