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
