[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg armhf patch acceptance status?


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 <lkcl@lkcl.net> wrote:
On Tue, Sep 7, 2010 at 12:01 PM, Konstantinos Margaritis
<markos@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.


 this is PRECISELY why i advocate - and continue to advocate - a build
system based around bitbake (NOT REPEAT NOT THE ENTIRE OPENEMBEDDED

 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


Reply to: