Helmut Grohne wrote:
These were my points.
On Sat, Jan 07, 2012 at 10:25:17PM +0100, Helmut Grohne wrote:
On Sat, Jan 07, 2012 at 02:53:46PM -0400, Joey Hess wrote:
But update-catalog can get new switches that handle the transition, and
debhelper can update the code to use them.
Ok. Let's evaulate what could be changed about update-catalog.
1) package catalog.
As per Daniel's request the package catalogs are now created at build
time, so update-catalog no longer touches them. The only place we
still touch the package catalog is to remove it (being an unowned
file in /etc) to transition to a proper configfile. So we would add
some update-catalog --transition-catalog to the debhelper preinst. It
would have do the magic to detect whether this transition is actually
necessary.
This --transition-catalog would do harm to the system when invoked by an
administrator since it relies on the broken behaviour of debhelper's
prerm and the creation of the conffile by the package upgrade.
Your patch already has the preinst calling update-catalog. AFAICS,
update-catalog could check with dpkg-query if the file is not owned
by a package, and not remove it unless this was the case, and it was
called with --transition.
In the unlikely event that the admin called it, it would detect that
the file was a conffile and not delete it.
Essentially the transitional code that I put into preinst would be moved
to update-catalog. I honestly do not see the value in this. In fact it
the complexity is even larger since we now have to depend on a newer
version of sgml-base
I do not see any complexity in a versioned dependency;
dh_installcatalogs already adds one.
and if we really need to apply further fixes we
need to change two packages now.
No, you just change sgml-base in a manner consistent with its new interface.
debhelper does not enter this highly hypothetical scenario.
Not mentioning the combinatorial
explosion of version combinations (of debhelper and sgml-base)
AFAICS the explosion results in 4 combinations.
Another
argument against this move is that it makes removing the transitional
code much harder.
Well, it's what, 3 lines? The difference is that it's 3 lines in one
place.
--
see shy jo
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org