Bug#477751: [ping] Re: Bug#477751: tackling this bug

2012-04-15 Thread Helmut Grohne
Hi Joey,

There is still no progress on this release critical issue. Given the
number of affected packages that will need a rebuild and the freeze in
June, I ask for action. Can you comment on my reasons against the
proposed change to sgml-base or come up with a solution yourself?

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.
 2) root catalog.
The package catalog is currently removed and readded to the root
catalog during every upgrade. This is to change, but the next upgrade
will still do the removal. So the --transition-catalog would do this
as well.
 
 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.
 
 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 and if we really need to apply further fixes we
 need to change two packages now. Not mentioning the combinatorial
 explosion of version combinations (of debhelper and sgml-base). Another
 argument against this move is that it makes removing the transitional
 code much harder.

Helmut



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#477751: [ping] Re: Bug#477751: tackling this bug

2012-04-15 Thread Joey Hess
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