Re: [Synaptic-devel] Using synaptic

[Panu Matilainen]

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.

> 
> > 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)

Would pretty much explain the state of things I think.


> > 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 :)

-- 
    - Panu -