Re: [Synaptic-devel] Using synaptic

[Kern Sibbald]

Hello,

Please see my comments below:

On Tue, 2003-08-12 at 12:04, Panu Matilainen wrote:
> Quoting Kern Sibbald <address@hidden>:
> 
> > Hello,
> > 
> > On Tue, 2003-08-12 at 11:20, Panu Matilainen wrote:
> <snip>
> > Yes, you are right in the case of mc. I failed to notice that the
> > depends was =.
> 
> ..and so it is for galeon and many others as well:
> galeon: Depends: mozilla (= 35:1.0.2) but 35:1.2.1-26 is installed
> 
> > > 
> > > > 
> > > > 
> > > > > Usually the problem is actually a
> > > > > problem of rpms installed with "rpm --no-deps" (or whatever the
> > option
> > > > > is, I use debian :) 
> > > > 
> > > > In my case, I never installed any of the above programs with the
> > > > exception of wml.  It is possible they were installed with the
> > > > --nodeps option, but if so, they were installed that way by
> > > > the RedHat upgrade program.
> > > 
> > > Anaconda doesn't use equivalent of --nodeps BUT it also doesn't guarantee
> > a
> > > consistent rpmdb as a result of an upgrade. If you stick with RH-only
> > packages
> > > then it's "guaranteed" by RH testing/QA that the result is always sane but
> > once
> > > you add 3rd party packages to the mix .. well, chances are things start
> > > breaking. apt and thus synaptic are designed to produce a consistent state
> > after
> > > any operation, even if it means removing packages which for example
> > anaconda
> > > never does.
> > 
> > What I found strange was that RH7.3 was clean except for one package,
> > which was easy to fix.  In this case, there are a lot of packages
> > broken.
> 
> Strange indeed.. I fail to see how a single 3rd party package would cause 
> such a
> mess.
> 
> > 
> > > 
> > > > 
> > > > In the case of wml, I installed it using checkinstall, which
> > > > created the rpm for me. During the build, which I did manually
> > > > before invoking checkinstall, there were no errors.
> > > > 
> > > > > 
> > > > > What you can also try is to call "apt-cache show gcc" and see if apt
> > > > > lists this suspicous dependencies too.
> > > > >  
> > > > Here is the output from apt-cache:
> > > > 
> > > > ===
> > > > apt-cache show gcc
> > > > Package: gcc
> > > > Section: Development/Languages
> > > > Installed Size: 11592
> > > > Maintainer: Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
> > > > Version: 3.2.2-5
> > > > Pre-Depends: /bin/sh, /bin/sh, /sbin/install-info,
> > > > rpmlib(CompressedFileNames) (<= 3.0.4-1), rpmlib(PartialHardlinkSets)
> > > > (<= 4.0.4-1), rpmlib(PayloadFilesHavePrefix) (<= 4.0-1)Depends:
> > /bin/sh,
> > > > binutils (>= 2.12.90.0.7-1), cpp (= 3.2.2-5), glibc-devel (>=
> > > > 2.2.90-12), libc.so.6, libc.so.6(GLIBC_2.0), libc.so.6(GLIBC_2.1),
> > > > libgcc (>= 3.2.2-5)
> > > > Conflicts: gdb (< 5.1-2)
> > > > Provides: gcc (= 3.2.2-5)
> > > > Obsoletes: gcc3, egcs
> > > > Architecture: i386
> > > > Size: 4518355
> > > > MD5Sum: aa544de315b6ba5478d3f6e0c15d0208
> > > > Filename: gcc-3.2.2-5.i386.rpm
> > > > Description: Various compilers (C, C++, Objective-C, Java, ...)
> > > >  The gcc package contains the GNU Compiler Collection version 3.2.2.
> > > >  You'll need this package in order to compile C code.
> > > >  =====
> > > > 
> > > > I notice that the bogus dependency for glibc-devel is
> > > > there. 
> > > 
> > > How is gcc's dependency on glibc-devel bogus? 
> > 
> > It is bogus because glibc-devel should not be needed. Unless
> > I am mistaken, glibc-devel is needed if you are changing glib.
> 
> No, the foo-devel are needed when you're developing something using foo 
> library.

OK.

> 
> > 
> > > You won't be able to do much with
> > > a C compiler without the standard header files :)
> > 
> > Well, I can assure you that glibc-devel is not loaded, AND
> > I have absolutely no problem compiling.
> 
> address@hidden pmatilai]$ rpm -qf /usr/include/stdio.h
> glibc-devel-2.3.2-27.9
> 
> I fail to see how you could compile just about anything without that.. which
> leads me to think that maybe your rpmdb is the thing that's broken here, the
> packages themselves might be on the filesystem but not on rpmdb (for whatever
> reason)

Ah, I think you have hit the nail on the head.  For example,

rpm -qf /usr/include/stdio.h
file /usr/include/stdio.h is not owned by any package

So, it looks like my database got messed up during the
upgrade.  Thanks to Synaptic, it was clean just before
the update.

> 
> Would pretty much explain the state of things I think.

Yes, now I just need to fix it.

> 
> 
> > > 4) If not .. you're up to some amount of manual fixing...
> > 
> > OK, that is what I suspected.  You might want to think about
> > some way that one could use Synaptic in these cases.  It seems
> > to me that if I could exclude files to be dropped, I could
> > then go through the list one at a time.  In addition, in some
> 
> Never tried to fix things with synaptic (I tend to use apt-get directly 
> myself)
> but should be doable just as well, it's a question of choosing necessary bits 
> to
> (re)install and perhaps remove some packages, even if temporarily. 
> 
> > cases, I would want Synaptic to totally ignore the unsatisfied
> > dependencies -- for example in the case of wml.
> 
> Being nitpicky about unsatisfied dependencies is bolted deep into apt library,
> not easily changable I'm afraid. 


> Would be nice to have it as an option
> occasionally, just for the sake of recovering from messes like this :)

I second that.

Thanks,

Kern

signature.asc
Description: This is a digitally signed message part