Hi Joey,
sgml-base 1.26+nmu2 has been accepted in sid. Can you go ahead and
upload debhelper? I talked to the release team and will take care of the
binnmus.
Helmut
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Mon, Apr 30, 2012 at 05:52:35PM +0200, Helmut Grohne wrote:
On the debhelper side it should be enough to remove all remaining calls
to update-catalog and introduce a dependency on the changed sgml-base. I
did not test this thus far.
I worked out the remaining bits and tested them. For
Helmut Grohne wrote:
I ask for feedback on this combination of patches. Since the bug is
assigned to debhelper now, I explicitly pull in the sgml-base
maintainers (who seem to be MIA).
Right. As I think I've posted before to this bug, I will
move ahead with the debhelper changes as soon as
On Fri, Apr 27, 2012 at 10:54:01AM -0400, Joey Hess wrote:
It certianly seems feasible to convert it to a symlink into /var.
I worked out the sgml-base part of the patch. It will turn the super
catalog into a symbolic link from /etc/sgml/catalog to
/var/lib/sgml-base/supercatalog and update the
Helmut Grohne wrote:
I worked out the sgml-base part of the patch. It will turn the super
catalog into a symbolic link from /etc/sgml/catalog to
/var/lib/sgml-base/supercatalog and update the latter file using
triggers. The loosing of user configuration will persist in all detail
until
On Mon, Apr 30, 2012 at 12:24:52PM -0400, Joey Hess wrote:
Helmut Grohne wrote:
On the debhelper side it should be enough to remove all remaining calls
to update-catalog and introduce a dependency on the changed sgml-base. I
did not test this thus far.
Won't dh_installcatalogs also need
Helmut Grohne wrote:
On Mon, Apr 30, 2012 at 12:24:52PM -0400, Joey Hess wrote:
Helmut Grohne wrote:
On the debhelper side it should be enough to remove all remaining calls
to update-catalog and introduce a dependency on the changed sgml-base. I
did not test this thus far.
There are
On Thu, Apr 26, 2012 at 06:18:40PM -0400, Joey Hess wrote:
This is why I originally recommended that the registration process be
converted to use triggers. A [directory full] of catalogs, and a root catalog
file automatically generated from them (which need not be a config file
in /etc) is a
Helmut Grohne wrote:
On Thu, Apr 26, 2012 at 06:18:40PM -0400, Joey Hess wrote:
This is why I originally recommended that the registration process be
converted to use triggers. A [directory full] of catalogs, and a root
catalog
file automatically generated from them (which need not be a
Helmut Grohne wrote:
So we seem to agree that both solutions (present vs. adding --transition
to sgml-base) are doable and both have their own problems. Are you still
interested in pushing the transitional code to sgml-base? Your arguments
have convinced me that it could work. I have not yet
On Thu, Apr 26, 2012 at 01:57:33PM -0400, Joey Hess wrote:
While I'm leaning toward just putting the code in debhelper,
I am worried about another issue in the patch. It makes
update-catalog be called only on new install, not upgrade ([-z $2]).
But then, if a catalog is added to an existing
Helmut Grohne wrote:
It gets even worse. Consider the case where a maintainer removes a
catalog from an existing package and stops calling dh_installcatalogs.
Then the root catalog would contain a dangling reference and there
really is no way to fix this anymore, because our code is never
Joey Hess wrote:
This is why I originally recommended that the registration process be
converted to use triggers. A file fill of catalogs, and a root catalog
^ directory full
file automatically generated from them (which need not be a config file
in /etc)
Helmut Grohne wrote:
In the unlikely event that the admin called it, it would detect that
the file was a conffile and not delete it.
An admin could call update-catalog --transition for a package that was
not rebuilt with the newer debhelper. In that case harm would still
happen. Do you
On Tue, Apr 17, 2012 at 09:08:30AM -0400, Joey Hess wrote:
Helmut Grohne wrote:
An admin could call update-catalog --transition for a package that was
not rebuilt with the newer debhelper. In that case harm would still
happen. Do you have an idea about how to prevent this?
Since this is
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
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.
Hi Joey,
Thanks for your quick response after the ping.
On Sun, Apr 15, 2012 at 02:47:03PM -0400, Joey Hess wrote:
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
Helmut Grohne wrote:
* preinst will do the tricky transition part. If it is called during an
upgrade and /etc/sgml/$package.cat is not owned by any package (this
is currently the case), then it fixes up the installation. The old
prerm will have the package catalog removed from the
Hi Joey,
thanks for your response.
On Sat, Jan 07, 2012 at 01:01:56PM -0400, Joey Hess wrote:
Helmut Grohne wrote:
* preinst will do the tricky transition part. If it is called during an
upgrade and /etc/sgml/$package.cat is not owned by any package (this
is currently the case),
Helmut Grohne wrote:
I agree that the complexity should not reside in debhelper templates.
However that is already the case. The entire code that is responsible
for #88010 already is contained in debhelper. It is debhelper's prerm
that removes the package catalog from the root catalog. And it
Hi Joey,
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
Hi Daniel and Joey,
I took some more time to look at Daniel's proposal and managed to come
up with an implementation which consists of one debdiff to only
debhelper (no sgml-base changes).
On Mon, Dec 05, 2011 at 12:05:26AM +0100, Daniel Leidert wrote:
(1) Register the catalog, if it exists
Hi Daniel,
On Mon, Dec 05, 2011 at 12:05:26AM +0100, Daniel Leidert wrote:
My thoughts on this are pretty easy. There are IMO three mechanisms to
use:
(1) Register the catalog, if it exists (and unregister any registered
catalog, if it doesn't exist anymore). So users can remove the package
Helmut Grohne wrote:
Good. This would also necessitate a versioned dependency on sgml-base.
Yes, easy since it already uses misc:Depends.
Do you want a diff for debhelper?
Would be appreciated.
--
see shy jo
signature.asc
Description: Digital signature
tags 477751 +patch
thanks
Hi,
I finally took the opportunity to work on this bug. As Joey Hess pointed
out the first thing to change is update-catalog. On the other hand
surely the debhelper snipped *will* have to change, because it
unconditionally removes a file in /etc. So let us have a look
Helmut Grohne wrote:
So what are your thoughts on this?
I haven't considered all the implications... Will the new sgml-base
work ok with the old postinst? With mixtures of the new and old
postinsts?
I'm happy moving ahead with the debhelper changes as soon as sgml-base
is in unstable.
--
see
Hi Joey,
thanks for your quick answer.
On Sun, Dec 04, 2011 at 05:25:42PM -0400, Joey Hess wrote:
I haven't considered all the implications... Will the new sgml-base
work ok with the old postinst? With mixtures of the new and old
postinsts?
Good question! Let's look at them individually. The
Am Sonntag, den 04.12.2011, 13:06 +0100 schrieb Helmut Grohne:
[..]
So what are your thoughts on this?
My thoughts on this are pretty easy. There are IMO three mechanisms to
use:
(1) Register the catalog, if it exists (and unregister any registered
catalog, if it doesn't exist anymore). So
29 matches
Mail list logo
