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 listmas...
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 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 con
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.
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 al
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 pa
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:
> 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 n
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
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 /e
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 i
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 existi
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 ye
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
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
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 t
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 th
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 po
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
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
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 cas
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 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 (an
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
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 pac
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 use
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. T
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
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 at
29 matches
Mail list logo
