Re: Some questions about dependencies
On Fri, May 02, 2003 at 12:01:22AM +1000, Anthony Towns wrote:
> On Thu, May 01, 2003 at 11:05:43AM +0200, Sven Luther wrote:
> > On Sat, Apr 26, 2003 at 01:21:54AM +1000, Anthony Towns wrote:
>
> > > > most: (110) .. xmms-msa xplanet xprint-xprintorg xwelltris/arm xwelltris/mips zope zsh-beta ztutils aolserver-nscache/arm aolserver-nsencrypt/arm apmd auto-apt bbappconf bbpager bincimap blender blt boost brltty cfitsio
> > > ...along with some 109 other packages, which are listed.
> > Well, i am not sure that all of these 109 packages are listed,
>
> No, because listing them each time would be irritating. Once there are
> more than 20 or so, it only lists the most recent 20, and includes a
> ".." to indicate there are more.
Well, fine with me, but then how in hell can you check what is really
going on, and find what package(s) is(are) holding a given package to
enter testing and can focus your effort on solving said problem.
If the uptdate_output is going to be only a simple indicative file, what
about generating also a more complete file, preferably in a way easier
to parse by a program, and which could be used to transfer this info to
the PTS, which already contains some of this info, but by no way all,
and even if some info is there, there is no way of knowing if there is
something more or not.
>
> > I don't think there are other reason, but maybe the update_output could
> > be made a bit more verbose in these cases :
> > 1) list all packages in this case as uninstallable.
> > 2) maybe list both the package that is trying to enter testing and
> > (between parentheses or something) the packages that they would break.
>
> > > > trying: cfitsio
> ^^^^^^^
> the (source) package that is trying to enter testing
>
> > > > skipped: cfitsio (1144+9)
> > > > got: 13+0: a-4:a-9
> > > > * arm: fv, libcfitsio-dev, libcfitsio2
> ^^ ^^^^^^^^^^^^^^ ^^^^^^^^^^^
> the (binary) packages (on arm) that would break
Yes, i understand, that solves the 2), appart from the fact that it is
mayhap not complete, and it is not easy to parse automatically. What
about 1) ? Packages not in testing, but which cannot be installed in
testing because they are not valid candidates ?
What can you say me about :
trying: hardware-monitor
skipped: hardware-monitor (982+40)
got: 23+0: a-4:a-5:h-6:i-8
* i386: hardware-monitor
For example ? This apparently would break no other package, appart from
hardware-monitor, but since it is not yet in testing, i don't see how it
could break. There are other entries, but none show more information
than that.
Hardware-monitor is a gnome2 applet, and as such it depends on gnome2
stuff, which is not yet in testing, or something such, but there is no
way to get that information from update_output. But then, update_excuses
show :
# hardware-monitor (- to 0.4-1)
* Maintainer: Sven Luther
* 12 days old (needed 10 days)
* Valid candidate
* Depends: hardware-monitor libbonobomm1.3
* Depends: hardware-monitor libbonoboui
* Depends: hardware-monitor libbonobouimm1.3
* Depends: hardware-monitor gconf2
* Depends: hardware-monitor gconfmm2.0
* Depends: hardware-monitor libglademm2.0
* Depends: hardware-monitor libgnome
* Depends: hardware-monitor libgnomecanvas
* Depends: hardware-monitor libgnomecanvasmm2.0
* Depends: hardware-monitor libgnomemm1.3
* Depends: hardware-monitor libgnomeui
* Depends: hardware-monitor libgnomeuimm1.3
* Depends: hardware-monitor gnome-vfs2
* Depends: hardware-monitor gtk+2.0
* Depends: hardware-monitor gtkmm2.0
* Depends: hardware-monitor gnome-panel
* Depends: hardware-monitor libsigc++-1.2
So maybe, this is the list of the 1) packages, and you have to check
them recursively ?
Friendly,
Sven Luther
Reply to: