Re: [Synaptic-devel] Using synaptic

[Kern Sibbald]

Hello,

On Tue, 2003-08-12 at 11:20, Panu Matilainen wrote:
> 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.

Yes, you are right in the case of mc. I failed to notice that the
depends was =.

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

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

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

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

I did this and rechecked it before emailing the list.

> 2) Run "Update"

I have run Update several times, and always run it after I add
new packages.

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

I did this several times, and it always says that the broken packages
are fixed, and yet the same large list of packages to be removed
remains.

> 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
cases, I would want Synaptic to totally ignore the unsatisfied
dependencies -- for example in the case of wml.

Best regards,

Kern

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