Re: bootstrapping debian was: dpkg armhf patch acceptance status
On Fri, Feb 18, 2011 at 1:34 PM, Wookey <wookey@wookware.org> wrote:
> There is nothing wrong with the idea of using bitbake to bootstrap
> Debian, except that what you end up with is a set of fixes outside the
> Debian packaging.
there are clear reasons for why that has to be the case, which we've
gone over before.
> Even though it is harder and slower, I believe it a
> better long-term solution to do whatever it takes to get those fixes
> inside the packaging (or upstream, as appropriate).
the problem with that is that when you have a long-term series of
changes which can only be *considered* for inclusion once they are
all, entirely, complete, ready, done, dusted, reviewed and proven to
work.
the armhf port is just _one_ example which meets that exact criteria.
> I have refrained from writing long emails about the reasoning and
> practicialities of this because I was expecting to be able to have the
> discussion in person next week. Unfortunately luke won't be there to
> have the argument in person,
nope. don't want arguments / discussions in an environment where the
sponsors, genesi usa, would quite likely be happy if i was dead.
> but I hope even he'd agree that the
> 'best' solution is to do it in Debian proper.
yyup, definitely. perhaps suggesting a tool such as bitbake was
_necessary_ to galvanise you, wookey, and others, to consider such.
if you're serious about ensuring that "extra" patches are contained
within debian infrastructure, the idea that occurred to me, just last
night, was to have a per-architecture patches directory.
debian/patches.{archname} for example.
the trouble with _that_ is that it requires that, again, the patches
be accepted by the debian maintainer!
[we've _been_ over this (2 months ago), riku, et al].
individual debian maintainers might simply choose, on a whim, to
completely ignore individual per-arch or per-project patches, thus
totally undermining efforts to develop a particularly long-term
complex and self-consistent, self-referring set of developments [that
must, always will be intended for going *into* debian NOT being
maintained separately as a "fork"]
deltas-on-deltas *WITHIN* the debian infrastructure, creating tools
that are based on DEBIAN. perhaps those tools might choose to
leverage the power of bitbake AS A TOOL, WORKING WITHIN DEBIAN AND
SUITED TO DEBIAN AND HAVING NOTHING TO DO WITH OPENEMBEDDED
DISTRIBUTION, perhaps they might not.
so.
riku.
if you dictate "this discussion is at an end, because this sounds
like a debian forking tool", then there will be no way for anyone
involved with debian to work *collaboratively* on significant complex
long-term strategic changes that will end up being *in* debian NOT
repeat NOT i repeat NOT i repeat, again, with respect, NOT a fork *OF*
debian.
is that what you're saying? if so, please confirm and state
explicitly that it is your wish and intent to restrict and curtail
debian's future development, and that you are happy for the present
situation to persist.
if i have misunderstood your intent, i sincerely apologise, please do
clarify and perhaps aid the debian project by engaging in a discussion
which provides the project with the benefit of your experience and
creativity, to solve this particular strategic challenge.
l.
Reply to: