Re: Recent version of dpkg-maintscript-helper needed for BPO
On 02/13/2014 10:12 PM, Raphael Hertzog wrote:
> Hi Thomas,
> On Thu, 13 Feb 2014, Thomas Goirand wrote:
>> So I wonder, could dpkg-maintscript-helper be in another source package
>> than dpkg, so that it could be easily backported?
> Even if it was part of another package, it would have strong versioned
> dependencies against dpkg because this script is allowed to rely on
> various internal details of how dpkg is working that cannot be safely
> assumed when you're not coupled with dpkg.
> Even if it currently works by using only public interfaces of dpkg, it
> might need to be changed the day where dpkg gets smarter native conffile
> handling and we don't want to risk having a broken combination of
> Thinking a bit more about this, what we currently need is to restrict
> dpkg-maintscript-helper to a maximal dpkg version that is known to be
> compatible. So it might be doable but it will be painful to handle as
> it will require an update for each new version of dpkg. And the day where
> dpkg changes in a way that impact dpkg-maintscript-helper we're back to
> a situation with tight dependencies.
Thanks a lot for all of the details. I understand better now the design
choice and why it's within dpkg.
Looking at the script, it seems *very* complicated and hard to get it
directly right. I believe I could write a much simpler version for my
own needs (with less features, probably), reading what's been done in
So, what's your advice for writing a "backportable" dir_to_symlink function?
> I know that backporting dpkg is frowned upon
> by the backports maintainer but I don't really understand this. If the
> backport is prepared with care and acked by the dpkg maintainers, it
> should not be a big source of worries.
What is the argumentation against a backport of dpkg? Would it be easy
for me to backport dpkg; is it a strait rebuild, or is there anything
which has to be changed?
Thomas Goirand (zigo)