Re: [Synaptic-devel] Using synaptic

[Panu Matilainen]

Quoting Kern Sibbald <address@hidden>:

> Hello,
> 
> Thanks for your reply. The answers to your questions
> are below.
> 
> On Mon, 2003-08-11 at 23:51, Michael Vogt wrote:
> > On Mon, Aug 11, 2003 at 06:38:50PM +0200, Kern Sibbald wrote:
> > > Hello,
> > Hi,
> >  
> > thanks for your feedback.
> > 
> > > I recently upgraded from RH7.3 to RH9, and in the process
> > > pulled the latest Synaptic (0.4) from freshrpms.  Unfortunately,
> > > either I don't understand how it works, or the new Synaptic
> > > cannot be used.  Why? Well, it has found about 20 packages
> > > that are "broken" and it wants to remove them. 
> > 
> > Does that mean that the older version of synaptic does not have this
> > problem? Only 0.40? Or did you only tried this one?
> 
> With the older version (0.28 the last one before Gnome 2.0), I
> only had one broken package. Unfortunately, I am not certain
> whether or not the current problem existed. 
> 
> > 
> > > I want to keep most of the packages -- for example,
> > > it wants to remove fetchmail, galeon, gcc, gmc, and perl
> > > among others.  The problem is I cannot figure out any way
> > > to make Synaptic keep the packages. If I display the Programmed
> > > Changes, then click on a package and click on Keep, it
> > > insists on removing the package.
> > > 
> > > Some of the dependencies that it is finding for these "broken"
> > > packages are rather suspect too. For example, for gcc, it lists:
> > > Depends: glibc-devel(>=2.2.90-12)    
> > 
> > Is it possible that actually the update to rh9 made the situation
> > problematic? 
> 
> Yes, this is possible since RedHat doesn't use Synaptic.
> 
> > Can you please call "apt-get -u upgrade" and see if apt
> > wants to remove packages as well? 
> 
> OK, the output follows. It looks identical to what is in
> Synaptic.
> 
> =======
> address@hidden 7.3]# apt-get -u upgrade
> Reading Package Lists... Done
> Building Dependency Tree... Done
> You might want to run `apt-get -f install' to correct these.
> The following packages have unmet dependencies:
>   fetchmail: Depends: smtpdaemon
>   fwbuilder: Depends: libsnmp.so.0 but it is not installable
>   fwbuilder-ipf: Depends: libsnmp.so.0 but it is not installable
>   fwbuilder-ipt: Depends: libsnmp.so.0 but it is not installable
>   galeon: Depends: mozilla (= 35:1.0.2) but 35:1.2.1-26 is installed
>   gcc: Depends: glibc-devel (>= 2.2.90-12) but it is not installed
>   gmc: Depends: mc (= 4.5.55) but 1:4.6.0-4 is installed
>   gnome-libs-devel: Depends: gnome-libs (= 1.4.1.7) but 1:1.4.1.2.90-32
> is installed
>   ical: Depends: libtcl.so.0 but it is not installable
>         Depends: libtk.so.0 but it is not installable
>   imlib-cfgeditor: Depends: imlib (= 1.9.14) but 1:1.9.13-12 is
> installed
>   imlib-devel: Depends: imlib (= 1.9.14) but 1:1.9.13-12 is installed
>   mod_perl: Depends: httpd (>= 2.0.40) but it is not installed
>             Depends: httpd-mmn (= 20020628)
>             Depends: libapr.so.0
>             Depends: libaprutil.so.0
>   mod_ssl: Depends: httpd but it is not installed
>            Depends: httpd-mmn (= 20020628)
>   mutt: Depends: smtpdaemon
>   nss_ldap: Depends: nscd but it is not installed
>   perl: Conflicts: perl-NDBM_File (<= 1:1.75-34.99.6) but 1:1.75-34.99.6
> is installed
>   php: Depends: httpd-mmn (= 20020628)
>   redhat-config-httpd: Depends: httpd but it is not installed
>   wml: Depends: perl(File::PathConvert) but it is not installable
>        Depends: perl(HTML::Clean) but it is not installable
>        Depends: perl(Image::Size) but it is not installable
> E: Unmet dependencies. Try using -f.
> ====
> 
> What is interesting is that apt apparently cannot handle 
> releases of the form 1:xx   Look at Mozilla for example.
> The dependency is met but apt thinks it is not.  The
> same problem occurs for gmc.

No, the dependencies are *not* met in those cases. Both galeon and mc have a
dependency on the exact version of the other package, not <= or >= dependency.

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

> 
> 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? You won't be able to do much with
a C compiler without the standard header files :)
 
> 
> Bottom line:
> It looks like Synaptic is doing the right thing to show
> the broken packages -- at lease considering the information
> it has.
> 
> The question is: "do I need to correct this manually" or
> is there some way to do it in Synaptic?  

1) Make sure your /etc/apt/sources.list (editable from synaptic as well of
course) actually points to RH9 repository and not 7.3 or something else
2) Run "Update"
3) See if "Fix broken packages" would do anything remotely sane (it can on
occasion lead to massive removal of packages which you might not want)
4) If not .. you're up to some amount of manual fixing...

> 


-- 
    - Panu -