Re: Bug#531581: Critical problems on hppa and ia64 buildds
[Removing -devel and hppa, re-adding the bug report.]
Luk Claes <luk@debian.org> wrote:
>>>>> The one on ia64 breaks the buildd's chroot and looks to be easily solved
>>>>> by making sure that the maintainer scripts don't fail when the missing
>>>>> command is not available.
>>>> ?
>>>>
>>>> It could be easily solved by making sure that nothing on the buildd
>>>> installs packages without installing their dependencies.
>>> A patch is appreciated, thanks for your cooperation.
>>
>> Excuse me - that should already be guaranteed by dpkg, or am I missing
>> something? If it isn't on that machine, what kind of patch should I
>> write?
>
> That it apparently is not already guaranteed by dpkg or it would not
> happen and that it only seems to happen with your package?
I'd be glad to fix it if only someone could give me an idea what is
wrong with it.
I have tried to analyse the build log in detail; it seems I missed the
point in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530832#15, but
I still hold that what I said in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530832#51 regarding
this bug (in the second half of the mail) is true. I summarized it in
the following message:
,----
| texlive-base is installed and trying to be removed in the
| initial apt-get run, although its dependencies texlive-doc-base,
| tex-common, texlive-base-bin, and texlive-common are not present.
`----
In other words, the buildd is in a broken state even before it tries to
install the Build-Deps of the package. It has texlive-base installed,
but none of its direct dependencies.
So far, no one has answered to this reasoning. I'm open to being
educated and learn what is wrong. But to
> Apparently you don't want to change your package to cope with it
What should we do? Add a line in debian/control:
Depends-and-I-really-mean-it-please-please-dpkg: texlive-doc-base (>= 2007), tex-common (>= 1.11), texlive-base-bin (>= 2007-13), texlive-common (>= 2007)
>, so I
> guess the only other option is to make the build environment cope with
> your package (which might be actually implementing the behaviour you
> expect and seems to be written in policy).
As I see it, the other option would be to log into the chroot and
fix or uninstall broken packages.
Regards, Frank
--
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg
Reply to: