[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#279232: What about perl-bug #279232?



On Sat, May 07, 2005 at 03:12:54PM +0100, Colin Watson wrote:

> > Given the recent freeze announcement, I'd suggest that regardless of
> > what other fixes are made, a good first step would be to get a fixed
> > doc-base (i.e. one that works with the current stable perl-base only)
> > package into stable-proposed-updates *now*.

> > If nothing else, this reduces the size of the problem if there's a point
> > release prior to sarge.

> I agree. Also, having a doc-base in sarge that's fixed in the way you
> describe means that we shouldn't have this particular incarnation of the
> problem again, and it would mean that at least we could tell people in
> the release notes to upgrade doc-base first. I think that would be
> acceptable as far as sarge is concerned.

I agree that requiring upgrade of doc-base first (along with the handful of
other packages we currently recommend upgrading first) is acceptable.

> > This wouldn't help. doc-base doesn't need to be touched at all for the
> > bug to appear. Perl gets itself in a non-working state...

> You've said this a couple of times, but I don't think that's true at
> all. Everything here seems to be working exactly the way it's been told
> to work, and certainly perl appears to be doing nothing wrong.

Well, <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279232&msg=44>
provided a pointer back to Bill's upgrade test at
<http://lists.debian.org/debian-devel/2005/04/msg01110.html>, suggesting
that this problem also hits defoma.

FWIW, gs-common in both sarge and woody depends on defoma, and defoma
depends on perl; and the problematic call to defoma-app happens in the prerm
script, which means that perl *should* still be in a configured state at
this point.

For gsfonts, the failure happens in the postrm script of the woody package.
In the sarge version, the font unregistering is (correctly) done in the
prerm, so this should not be an issue -- if we can figure out why File::Copy
isn't being found in the prerm.

> The problem is that the packages that call install-docs do so
> opportunistically (only if it's available), and so they do not declare a
> dependency on perl or doc-base. Thus, there is *no way* for them to make
> sure that install-docs is actually usable; it may be unpacked but not
> configured. Once the doc-base package enters the configured state, dpkg
> will have made sure that perl is configured too (as per the definition
> of Depends) and so install-docs will work fine. Bill's suggestion would
> therefore fix this bug, although I haven't quite decided whether it's
> more complicated than just making doc-base work with only essential
> packages. I could go either way.

IMHO, Bill's fix is more complicated.  Most packages (i.e., those using
debhelper) do check for executability of install-docs via "which", but at
least some of them use command -v, which means either finding and fixing
those packages or creating a wrapper script; and using such a wrapper script
would then make it impossible for packages or other scripts to directly
handle errors from install-docs if this was their intent.

Since either fix would require woody users to upgrade doc-base before
dist-upgrading to sarge, I would prefer the more robust solution of making
install-docs work with only essential packages installed.

> The following patch to doc-base avoids the use of File::Basename, so it
> should work with only perl-base. I've tested the substituted functions
> independently, but I have not yet tested the resulting package. Caveat
> emptor. Bill's suggestion should definitely be tried out too, since it
> would probably involve less code.

All things considered, I think the amount of code involved is about the
same. :)

> Long-term, it would be nice if there were a way for a package to have a
> simple way to test whether another package is configured, to supersede
> all these 'test -x' calls; perhaps a trivial wrapper around dpkg-query
> provided by dpkg in order that everyone does it the same way.

Hmm, yes, agreed...

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: