Re: dpkg armhf patch acceptance status?
On Fri, Feb 18, 2011 at 12:25 AM, Steve Langasek <vorlon@debian.org> wrote:
> Hi Luke,
allo steve.
> I think you are working from a buggy assumption here.
i'm pleased - and relieved - to see the word "think".
> The problem is not
> that infrastructure is lacking to let Konstantinos et al. get on with making
> an armhf port out of the Debian archive; the problem is that they are
> currently blocked on getting armhf *into* the Debian archive, because that
> requires agreement with the dpkg maintainers about how dpkg should behave to
> recognize this new architecture.
yes. i based my response on this problem.
> You may be right that a bitbake-compatible git repository is the absolute
> slickest way to nearly effortlessly maintain a delta against a distribution.
> But it doesn't actually matter if you're right about this, because "nearly
> effortless" is not "zero work", and it's *not* sustainable to carry a delta
> in the long term - which is why the (right) goal is to merge the armhf work
> into Debian so that there *isn't* a delta.
precisely. this is another, (clearer or at least different) way of
stating what i've been advocating. by having such a delta-maintaining
tool, complex sets of deltas can be maintained indefinitely, or in
fact completely reworked.
the fact that the delta-maintaining tool is maintaining deltas
against debian packages, which are themselves deltas against upstream
packages, does create some rather interesting challenges but i'm sure
that debian people are up to that without their heads melting, eyes
bleeding and any more screams emanating than would normally occur on a
day-to-day basis.
... in fact, *binggg*, light-bulb moment... now that i think about
it, why isn't the debian archive system *itself* being used for this
task?? ermm... the principle exists in the form of the debian kernel
source packages, right?
so why not use buildd to have debian packages that contain patches
and a preinst script that does "apt-get source {packagename}" and then
applies the patches [that markos is currently maintaining by hand].
call each of them armhf-patch-botchjob-{packagename}, for now, for all
i care - it's not like they're going to get uploaded to ftp.debian.org
any time soon, but they *could* be dumped on
ftp.armhf-in-development.debian.org hmmm [why couldn't they be
uploaded to ftp.debian.org?? i can't think of a reason why not..
anyone that installed them would just end up cluttering up
/usr/local/src or wherever the packages dumped and ran the patches on
the preinst-triggered debian-package source code...]
that approach would do the same bloody job, pretty much!!
... does anyone else understand that paragraph? could someone make
an attempt, in a similar vein to what steve has done, starting with
"so let me get this straight: let me reiterate that, please do correct
any assumptions made".
> Bitbake doesn't help with that goal;
not without some code - estimated to be approximately... 600 lines -
comprising a hybrid of python, shell-script and bitbake recipes [and
bitbake classes, if you're familiar with the terminology] that, at
their heart, kiinda replicate the functionality of buildd. the "first
version" might actually be simpler than that, because the "first
version" would be to *not* try to tackle cross-compiling, but would be
tasks consisting of nothing more than calling "dpkg-buildpackage -t
${DEBIAN_RULES_TARGET}". the "heavy lifting" - the vertical and
horizontal interdependencies - is what "bitbake-the-tool" is good at,
and is already coded and designed to do.
all the hybrid python+shell-scripts+recipes have to do is define the
horizontal dependencies (oh look, that's nothing more than reading
dpkg stuff, funny that, there's a python library for that); define the
vertical dependencies (oh look, those are pretty linear), and define
the links between the two [build done, install completed -> next
rdepend can proceed with "apt-get source" task]
i outlined this approach a couple months back on ... huh. debian-arm? yeah.
it was _completely_ misunderstood, with, as i understand it, numerous
people privately believing that i was attempting to take over debian,
or that i was recommending that years and decades of work by some of
the most committed debian developers should be completely abandoned in
favour of using openembedded i mean it was _really_ weird some of the
stuff i was hearing.
i had a prolonged, intensive and quite amicable discussion with
markos, clarifying many of the misunderstandings, and thus allowing me
to subsequently make a much clearer and concise description, which was
good.
but... yeahh, someone tell me: does the "use dpkg to manage deltas to
dpkg packages" idea fly, as an alternative? it'd hardly need any
coding (which is nice) - might even be able to create a script which
writes the dpkg-delta-package based on a template.
> the only way to help that goal is to
> have the sometimes-difficult conversations with the Debian maintainers that
> let us arrive at a consensus about how these things should be put together.
... and in the meantime, markos is under pressure to manually
maintain everything _without_ a delta-management tool, which puts
ongoing and ever-increasing pressure on what he can reasonably handle,
whilst those discussions are underway. re-read what he wrote. he's
effectively asking that the dpkg patch (which isn't acceptable as it
stands) be hurried up, because he's got a ton of stuff that's being
added to daily, piling up behind it.
out of concern that that pressure could result in hasty decisions
being made, i re-raised the solution i had envisaged, which i believed
- and believe - would be beneficial not just in this situation but for
other strategic tasks as well. hell, you _know_ i don't do things by
half measures, if a tool can do one job i make f*****g sure it can do
a dozen others, but i urge people to *ignore* those "other options"
for now and to look at ways in which potentially hundreds of waiting
deltas to debian packages can be reasonably managed.
but... you just _know_ there are going to be circumstances where such
a dpkg delta-management tool would be absolutely invaluable not just
now but also in the future.
l.
Reply to: