On 18 Feb 2003 16:45:35 +0100, Martin Josefsson <gandalf@wlug.westbo.se> posted, and _mailed_too_, in message: <1045583134.18515.159.camel@tux.rsn.bth.se>: > On Tue, 2003-02-18 at 15:37, Arnt Karlsen wrote: > > > > Patch-o-matic is cool in that it handles a lot of this > > > stuff without problems, but if you are applying too many patches > > > on top of each other, you should resolve any conflicts yourself... > > > > ..this attitude is not good enough. As a minimum, all the base > > patches should make it into "my" patched kernel, starting from a > > _clean_ Linus tree. The extras etc, should stop and warn that > > "this" patch does not"allow" etc "that" patch, "so, you need to > > choose which you want". > > This attitude is perfectly fine, if you don't like it, start running > an OS you can't modify. You find this attitude _everywhere_ in the ..we disagree. Now, note I said "my" etc. This attitude has the wee problem it makes patch testing a little harder for the newbies, because the newbies never learns how they can report back new failures, which the attitude guys hasn't been been smart enough to prevent. This again has ramifications on development. Your call. > Linux community. If you want to be able to do more advanced stuff you > will have to actually learn how to do parts of it yourself. ..noted. ;-) > I can tell you that patch-o-matic already does a lot of things to help > you apply all these patches. With regular patch files you would have > to fix a lot by hand. ..this far, I have learned "regular patching" may be slower, but less trouble. > Base patches go in without any problems here, it's some of the extra > stuff that's the problem. ..agreed, I've also seen a few base patches fail on Red Hat trees. > If you want that kind of dependency system you will have to fix it > yourself, I don't think any of the developers are interested in > building it. ..I'll consider it next time I have a good slack in my schedule. > > ..preferably, patch-o-matic should also work as good with Red Hat > > kernels, up to and including "base", as Red Hat and its derivatives > > are the entry level distros. From "extra and up", work from the > > vanilla kernel trees. > > This you would definately have to fix yourself. Do you have any idea > what vendor kernels include? They include several hundred patches. ..possibly, chk any kernel source srpm. > > ..and, I'd like to have Patch-o-matic log what it does, to a file, > > either as the default, or as a suggestion on how to do it from the > > cli, in a readme, as you see, people come here to learn. > > We live in a do it yourself world, you can't rely on other people > building the stuff you want. If you want to see it built you will > probably have to build it yourself. ..agreed. Meanwhile, the Patch-o-matic readme might be made more useful for newbies after including a pointer to these wee '2>&1 >' tricks in, say, the abs-guide, unless it hurts someone attitude toe or something. Newbies who use patch-o-matic are smart enough to read and be made useful testing stuff for development. > If you modify patch-o-matic to do this stuff we will review the > changes and either accept (possibly after some modifications) or > reject them. > ..ok. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case.
