Re: Q: top three things you would like to change if that was easy?

[Niels Thykier <niels@thykier.net>]

> On 02/04/19 at 17:24 +0200, David Kalnischkies wrote:
>> ¹ with an exception for the 1% of packages which actually really need it
>> and are deploying DPKG_ROOT at least. The rest should really make due
>> with declarations of what it needs rather than buggy imperative scripts.
> 
> Can you summarize the current state of effort(s) for declarative
> equivalents to maintainer scripts? Asking for a friend who has not paid
> enough attention. :)
> 
> Lucas

Hi Lucas,

(Please CC me on replies if replies from me are wanted).

I believe the current state of effort(s) for replacing imperative
scripts with declarative equivalents has stagnated - at least in the
sense that there has been little visible progress for quite a while (the
most recent example I can find is from August 2015).

The "most" effort I know of is people around dpkg working to support a
new database format, which /in theory/ could replace some of the
imperative uses.  Though, that rewrite will probably be a release or two
away from deployment and in itself might not provide any benefits to the
situation (i.e. additional work might be needed on top of that to
materialize any benefits).

To my knowledge, the following "high priority" targets would resolve
most of our imperative usage:

 * Declarative rm_conffile/mv_conffile
   - Common reason for a package to "regress" (i.e. go from "no-scripts"
     to "has-maintscript")
 * Creation and closure/removal of system users/groups for services
 * Management of services (the autoscripts generated by
   dh_install{init,systemd})
 * Management for alternatives and diversions.

A "nice" addition would be:

 * Declarative symlink_to_dir/dir_to_symlink migration (could come as a
   part of the new database format, but I doubt it)
   - But for most parts, we can probably "wait this one out" as
     usage of symlinked docs slowly "dies out".

Almost all of these need some form of support from dpkg to become fully
declarative.  Admittedly, we can do a bastardized PoC solution involving
an Essential:yes package to implement the logic, a declarative
"do-this-for-me" file and "dummy" maintscripts to trigger the logic
while we wait for proper dpkg support - but I think people will have
more concerns with that PoC than just wait it out.

There is also a wiki page dedicated to this issue (which covers the high
priority cases):
 * https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging

Hope that gave your friend the insight they needed in the situation.

Thanks,
~Niels