Luke, 1. My name is Konstantinos, or Kostas, or if you prefer, just call me markos. It's not konstantinos, and it's not konstantinous. 2. My workload is big even without considering "crazy" solutions of distro-wide bitbake-integrations. If you so strongly believe that this method works so great, feel freel to demonstrate it by *proving* it works. Otherwise, it's just noise that distracts me from my work. I seem to remember someone famous saying sth like "show the code or sth..."... :P So, please don't hijack the thread and the bug report, with something totally irrelevant.
Konstantinos (http://en.wikipedia.org/wiki/Constantine_%28name%29) On 17 February 2011 22:19, Luke Kenneth Casson Leighton <l...@lkcl.net>wrote: > On Tue, Sep 7, 2010 at 12:01 PM, Konstantinos Margaritis > <mar...@genesi-usa.com> wrote: > > Hi all, > > > > I really would like to know the stance of the dpkg maintainers regarding > the > > armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file > as > > bug reports, but without the dpkg patch, those patches would be useless, > so > > I'm holding back, but that in the meantime increases the workload as > newer > > packages appear all the time and I have to forward port the armhf patches > all > > the time. > > konstantinous, > > this is PRECISELY why i advocate - and continue to advocate - a build > system based around bitbake (NOT REPEAT NOT THE ENTIRE OPENEMBEDDED > INFRASTRUCTURE AS ASSUMED BY SOME PEOPLE WHO THEN ASSUMED I WAS A > F*****G IDIOT FOR EVEN MENTIONING BITBAKE) > > the reason is plain and simple: patches-to-packaging such as the > patch to dpkg you refer to can be applied easily by bitbake > infrastructure prior to a build, in fact the entire debian packaging > of dpkg and other packages that you are maintaining differences on can > themselves be committed to a bitbake-compatible git repository, that > git repository uploaded, managed, distributed and generally worked on > by *other* people not just yourself; > > each set of patches-to-debian-packages, as they *are* accepted > upstream can then be *dropped* from the git repository; > > and so on and so forth. > > there are damn good reasons why i mentioned and advocated the use of > bitbake as both a package-development as well as a build AND a > cross-build tool, precisely to help _you_ to cater for the exact > circumstances in which debian developers now find themselves causing > quite some awkwardness as the build progresses. > > perhaps, even, horror-of-horrors or hope-beyond-hope depending on > which side of the fence you sit, such a system might even help to > manage the scenario where large-scale en-masse changes could be > planned, developed, made and reviewed to ubuntu packages, thus > allowing ubuntu to actually be what it should have bloody well been in > the first place: nothing more than an extra debian repository with > overrides for certain packages. > > what stops that from being desirable let alone feasible is the fact > that ubuntu is designed to be idiot-proof, thus only the idiots use > it, and that keeps them the bloody hell away from debian, which is > GREAT! :) > > l. >
