Re: Bug#594179: dpkg armhf patch acceptance status?
Hey
Trying to kick the dust a bit as having the triplet "in the air" is
kind of an unhappy situation for armhf :-)
On Wed, Sep 08, 2010, Guillem Jover wrote:
> We currently need something like this in dpkg-dev because the mappings
> need to be bidirectional, as dpkg-dev needs to be able to convert
> from GNU triplet to Debian architecture and the other way around.
>
> Steve wondered why this is the case, and that's because for
> cross-compiling purposes dpkg-architecture infers the host architecture
> from the CC environment variable through the -dumpmachine option.
> Chaning this is possible but, would break a current way of
> cross-compiling which has been around for a long time.
So this use case is "CC=arm-linux-gnueabi-gcc dpkg-buildpackage" and it
just guesses the -a flag that you should have set?
> The toolchain has the same triplet for binary incompatible producing
> objects, which seems like a bug/misfeature to me, and that's one of
> the assumptions dpkg-dev has relied on, in the same way as multiarch
> when deciding to use the triplet as a unique token for the installation
> directories.
You describe this as a bug/misfeature, that might be true but I don't
think we can challenge this usage of triplets in the upstream
toolchain, and multiarch is moving to having its own tuples instead now
(http://wiki.debian.org/Multiarch/Tuples).
> This also causes issue with not being able to have installed two
> cross-toolchains for say armel and armhf as they share triplet,
> although you can use the armel toolchain with few options to build for
> armhf, but then you'd need to specify those as part of the CC variable.
Even if we could co-install them, I'm not sure how
/some-armel-path/arm-linux-gnueabi-gcc and
/some-armhf-path/arm-linux-gnueabi-gcc could helpfully be installed on
the same system :-/
It's a real limitation of the upstream toolchain.
> Also that also happens with biarch, you can produce i386 binaries from
> an x86_64 toolchain, yet they both have their own triplet.
Yes but x86 goes to the other extreme, with separate triplets for
compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
triplet is not a good ABI specifier.
> Anyway, ideally I'd rather see this addressed by giving armhf a real
> triplet, which would also make multiarch life way easier as there'd not
> be any need to define an artificial set of neutral architecture names
> to be able to place objects in the file system. But if this is not going
> to happen, and thus the assumptions dpkg-dev is making have been just
> wrong, then I'd rather drop the bidirectional mappings, and be done
> with it. This will need careful consideration though, as it's breaking
> a current interface, but something that could be done for dpkg 1.16.x.
Having a separate triplet (not using the vendor field) like e.g. lpia
would mean a lot of pain IMO, and we'd have to fix many packages to
cope with it, including reaching out to upstream etc. It was pain for
lpia for sure.
We could have an additional set of preprocessor macros which dpkg
checks for to decide which Debian architecture we're talking about; the
the would only be done if there is more than one architecture using the
same triplet in dpkg tables. This alone is a bit fragile though, as it
means that if a new ABI is introduced to an existing triplet and is not
immediately added as a new dpkg architecture, then people might be
picking the wrong dpkg architecture when using a toolchain defaulting
to thenew ABI.
I wonder whether it would be a good idea to use multiarch tuples
internally; dpkg would still have to map to/from GNU triplets, but it
would force implementors to think about their ABI. I am not sure how
we can ensure that we've mapped to the right tuple though. Neither am
I sure that the multiarch tuples are frozen already, so it might be too
early for that either.
Bye
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110217112730.ga19...@bee.dooz.org
Natalija nodod shaujamriiku!
Vecmilgravja veikalinjaa sodien var iegadaties shaujamo Kahr Arms MK9 Nav vajadziga ne atlauju, ne atlauju no policista! Neparproti, un mekle realaja rajonaa: http://www.bezatlaujas.info ! -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/auto-70568...@mail.icosmos.ru
Re: dpkg armhf patch acceptance status?
Loïc's latest post drew my attention back to this thread, where I see I had this message flagged for follow-up: On Fri, Sep 10, 2010 at 09:35:24AM +0200, Goswin von Brederlow wrote: > > I realize this is ideal, but: > > - there's been very strong upstream pushback on this, asserting that this > >is the correct triplet to use for both arm calling conventions, so if we > >require a distinct triplet for armhf (instead of using the vendor field), > >that's going to block any armhf port for quite a while (possibly > >indefinitely) > > - armhf was not the sole motivation for the proposal to define neutral > >architecture names; x86 was already a problem because of the changing > >triplets depending on which level of instruction set compatibility is > >targeted. *Both* of these examples show that GNU triplets are not > >defined in a way that they map directly to what we need for multiarch, so > >it's best to explicitly define our mapping externally. > > So even if you persuaded the upstream toolchain folks to specify a new > > triplet for armhf after all, I think we should still go ahead with a > > separate name mapping table for multiarch. > Note that uclibc also suffers this problems. x86_64-linux-uclibc is in > no way unique as different uclibc compile options create different ABIs > all with the same tripplet. We have a draft proposal for tuples to use in the filesystem paths for multiarch: http://wiki.debian.org/Multiarch/Tuples uclibc is included in the design, with a single identifier of 'uclibc'. We probably need to have a better definition here. Where is the right place to raise this point for discussion in Debian? Should I bring this up on the debian-embedded list? Are there other stakeholders who would have input regarding the array of available uclibc ABIs and how to specify these? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110217200306.gb11...@virgil.dodds.net
Re: dpkg armhf patch acceptance status?
On Tue, Sep 7, 2010 at 12:01 PM, Konstantinos Margaritis 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. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktineuwanracxggklgmludnwynge60p1xhhq9x...@mail.gmail.com
Re: dpkg armhf patch acceptance status?
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 wrote: > On Tue, Sep 7, 2010 at 12:01 PM, Konstantinos Margaritis > 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. >
Re: dpkg armhf patch acceptance status?
+++ Steve Langasek [2011-02-17 12:03 -0800]: > Loïc's latest post drew my attention back to this thread, where I see I had > this message flagged for follow-up: > > On Fri, Sep 10, 2010 at 09:35:24AM +0200, Goswin von Brederlow wrote: > > > > I realize this is ideal, but: > > > > - there's been very strong upstream pushback on this, asserting that this > > >is the correct triplet to use for both arm calling conventions, so if > > > we > > >require a distinct triplet for armhf (instead of using the vendor > > > field), > > >that's going to block any armhf port for quite a while (possibly > > >indefinitely) > > > > - armhf was not the sole motivation for the proposal to define neutral > > >architecture names; x86 was already a problem because of the changing > > >triplets depending on which level of instruction set compatibility is > > >targeted. *Both* of these examples show that GNU triplets are not > > >defined in a way that they map directly to what we need for multiarch, > > > so > > >it's best to explicitly define our mapping externally. > > > > So even if you persuaded the upstream toolchain folks to specify a new > > > triplet for armhf after all, I think we should still go ahead with a > > > separate name mapping table for multiarch. > > > Note that uclibc also suffers this problems. x86_64-linux-uclibc is in > > no way unique as different uclibc compile options create different ABIs > > all with the same tripplet. > > We have a draft proposal for tuples to use in the filesystem paths for > multiarch: http://wiki.debian.org/Multiarch/Tuples > > uclibc is included in the design, with a single identifier of 'uclibc'. We > probably need to have a better definition here. Where is the right place to > raise this point for discussion in Debian? Should I bring this up on the > debian-embedded list? Are there other stakeholders who would have input > regarding the array of available uclibc ABIs and how to specify these? Debian-embedded contains people who know about uclibc stuff. (ron, Bernard Link, virtuoso, Simon richter) Comments anyone? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110217225436.gu22...@dream.aleph1.co.uk
Re: dpkg armhf patch acceptance status?
On Thu, Feb 17, 2011 at 9:43 PM, Konstantinos Margaritis wrote: > 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. sorry! :) i have always spotted such auto-finger-typing errors in the past: i apologise for having allowed one to pass through my normally-vigilant attention span. > 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. i will be happy to do so with the proviso that i am financially rewarded for doing so, or can perceive that some significant financial and immediate reward will be gained by doing so. i apologise for having to add such a quite reasonable proviso but the value placed on significant strategic contributions - including "actual proven code", that i have made over the past fourteen years to free software has resulted in financial gain to others - often quite significant gain - frequently at my expense, and i believe that many would agree that it would be completely fucking stupid of me to allow said situation [spongeing off of my expertise and contributions] to continue. ESPECIALLY given that myself and my family face eviction due to having to prioritise payment of food, in order to stay alive, over payment of rent, since about, ooo, august. i trust, also, that you place a high value on the abilities of those whose time is best spent devising strategic contributions and advocating time-saving plans and designs, rather than also focussing their time on actually *implementing* those solutions as well? whilst it has to be said that there is case to be made for prioritising the contributions of people who _do_ then follow up by providing an implementation as well, it also has to be said that there are circumstances where people may or may not have the time, or even may simply not be as *quick* as someone else who may be able to implement said plan, but to dismiss the ideas on the basis that the contributor hasn't actually "turned it into code" is an argument that is increasingly beginning to look very very stale in the face of the increased complexity and inter-connectness of free software's overall place and parts. sorry, markos, but that does have to be said. > 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. i apologise for giving the impression such that you might consider the thread and the bugreport to have been either or both hijacked and/or irrelevantised. i am disappointed that you would even consider my idea to be same, as it was made in good faith as a way to assist you and save _you_ time, as well as being a way to reduce the stress of the "prioritisation" situation (where dpkg's patches is "holding up" development of armhf), such that others may be of assistance to you and the ongoing armhf efforts be more of a collaborative effort, as well as being possible within a much more "relaxed" working environment, and i am therefore at a loss. perhaps you or others might advise me as to the best way in which to present this idea, or perhaps you might reasonably wish to discuss it amongst yourselves or even here on the list _without_ prejudice, asking questions such as "what are you on about, weirdo?" to which i will be more than happy to respond with glee and wanton abandon, and might even stick to the topic at hand and thus help debian progress with this strategically important project. might i also respectfully advise that you consider, with respect, that far from _me_ "polluting" or "hijacking" the thread, it is _your_ views which have, most ironically, i must with some regret, hesitation yet the utmost respect at the same time, point out have "hijacked" the thread with matters that can be considered, by some, in fact to be "totally irrelevant". i say this with extreme care, with the utmost respect, without prejudice, and apologise most profusely to all recipients for having to raise this, and also have taken the care to remove the bugreport from the cc list so as not to further "pollute" or "hijack" the ongoing relevant and strategically important discussion. i also apologise to all concerned for having engaged with and incurred the wrath of employees of genesi-usa, who now appear to, most unfortunately, be universally to a man seeking some sort of retribution, and i apologise to all concerned for you having to witness, in public mailing lists, such responses with such an aim in mind. i also - again - apologise once more to genesi-usa employees for having called one of them out on "protectionist" practices which took place on public mailing lists, and for the subsequent fall-out and alienative (and importantly PRIV
Re: dpkg armhf patch acceptance status?
sorry, markos - and again, apologies to all, but i am actually now getting deeply concerned. allow me to ask you this, markos. why, if someone says, "i have an idea that could help you, and could help the debian project in general, it's complex, it's been misunderstood frequently in the past (not necessarily by you, personally and specifically), but i'd like to re-iterate in the context of this discussion how that idea may help", would you then say "your whole idea's s**t"? :) to illustrate, with some questions, why i am concerned at the response received: * are you, markos, pleased to be the sole exclusive developer on the armhf project, such that you wish to retain complete control of it until such time as it is finished? * are you, markos, *wishing* to impose stress and pressure onto debian developers, specifically the dpkg team? * are you, markos, wishing to deliberately cause yourself harm by placing *yourself* under stress and pressure, by deliberately dismissing ideas that would, if implemented, allow you to reduce both the amount of stress and pressure, as well as the dependence on yourself, allow others to participate at leisure and so on? because, ridiculous as it may sound, those are the only possible reasonable _honest_ motives for you being so dismissive of what i wrote. reducto ad ab... can't even remember the damn word... absurdum, logically we conclude that there could be a hidden and unspoken motive, instead. if there is, SPEAK it. please get it out into the open so that we may resolve it, and thus not have these continued ridiculous misunderstandings which are plaguing interactions with genesi employees on public mailing lists. i find that people forget, before speaking: archives are forever. i point this out to them, retrospectively, and they go ballistic, blaming _me_, against all logic, for their own words. so - SPEAK, markos. correct me if i have misunderstood, and i will apologise for any misunderstandings. l. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin_ars2fsvvcvuw6dg14jokug753sfpncxch...@mail.gmail.com
Re: dpkg armhf patch acceptance status?
Hi Luke, On Fri, Feb 18, 2011 at 12:06:27AM +, Luke Kenneth Casson Leighton wrote: > sorry, markos - and again, apologies to all, but i am actually now > getting deeply concerned. > allow me to ask you this, markos. why, if someone says, "i have an > idea that could help you, and could help the debian project in > general, it's complex, it's been misunderstood frequently in the past > (not necessarily by you, personally and specifically), but i'd like to > re-iterate in the context of this discussion how that idea may help", > would you then say "your whole idea's s**t"? :) > to illustrate, with some questions, why i am concerned at the response > received: > * are you, markos, pleased to be the sole exclusive developer on the > armhf project, such that you wish to retain complete control of it > until such time as it is finished? > * are you, markos, *wishing* to impose stress and pressure onto debian > developers, specifically the dpkg team? I think you are working from a buggy assumption here. 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. 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. Bitbake doesn't help with that goal; 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. Which is what this thread is about. :) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: dpkg armhf patch acceptance status?
On Fri, Feb 18, 2011 at 12:25 AM, Steve Langasek 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
> l
