up2date problem?

[Alexandre Oliva]

On Oct 13, 2003, Adrian Likins <alikins at redhat.com> wrote:

> 	New versions of up2date for fedora use a
> yum repo for fedora as the default channel now.

And I must say it's *very* cool.  I spent part of the weekend finding
repos to use and figuring out how to set things up, and I *love* it.
Here's the sources file I'm using (with entries I got from postings to
this list).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: up2date-sources-0.95
Type: application/octet-stream
Size: 1013 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20031013/5dadf21c/attachment.obj>
-------------- next part --------------

local-rawhide has a copy of rawhide's SRPMS and i386, with headers
generated locally with `yum-arch /l/mirror/redhat/rawhide'.  I tried
using the headers directly from rawhide, but then up2date would break
because headers.info mentioned headers for non-i386 arches, that I'd
chosen to not mirror, and then it fell apart.

Here are some notes of problems I noticed while trying these new
features:

- yum entries in the sources file mistakenly created with 4 columns
  raises exception

- 404 error in URL raises exception to tty, and proceeds to package
  selection without any packages to select

- exception when loading obsolete list for apt repository, when
  running GUI up2date.  I have got this only the first few times I ran
  it.  Now, even if I clear /var/spool/up2date, I no longer get the
  error.  Very odd.

- local dir package could recurse into arch-named subdirs, maybe even
  look for yum repo (or example file should suggest yum file:/ URL for
  this purpose).  Maybe a dir-recursive entry type?  file:/ feels
  slow.

- single-arch filtered rawhide doesn't work as a yum repository, as
  explained in the paragraph above.

- I get gh[123] debug messages while fetching pkg lists from dag's apt
repo

- it downloads headers even for packages that are already installed,
  bloating /var/spool/up2date

- it doesn't use http proxy set up with up2date --configure for
  non-rhn servers.  I worked around this by configuring a transparent
  http proxy for my home network, which I'd meant to do for quite a
  while :-)

- resolves dependency to athlon package from apt repo on an i686 box.
up2date -i mplayer, for example, requires lirc, whose athlon build is
selected from dag's repository, and them it refuses to install the
athlon package because it's an i686 box

- after `up2date -i some-package', its header file is removed.  Later
on, if we try to install another package that requires some-package's
header for dependency resolution, up2date enters an infinite loop
looking for the header in /var/spool/up2date (and all packageDirs, if
configured), because it doesn't fetch the header again.  Maybe it
shouldn't have removed them in the first place?
cd /var/spool/up2date && rm -f * fixes it.

- unsatisfiable dependency is reported as an exception,
without any reference to the missing package.

- it reports directory conflicts between packages that rpm will
install without any problem

- some dependencies are not properly identified or resolved.  I got
  crashes in dependency resolution in some cases, that I couldn't
  duplicate after installing other packages manually.  One
  reproducible example I remember is flac-xmms, that requires id3lib,
  but id3lib isn't brought in as a dependency.

- up2date -u --channel=<local yum channel> attempts to update packages
from other (apt and yum) channels

- up2date gui could use a button to select/deselect all channels

- dag's rh9 apt repo has mozilla-j2re 1.4.2-2, but he has
mozilla-j2re 1.4.2-4.  Even if I download it into a local yum repo,
up2date -u won't update to it, although rpm -U does without
--oldpackage.  If I rpm -e then up2date -i, it gets the newer
package.


Would you like me to file these into bugzilla?  All separate, or can
you see that some of them are just symptoms of a single problem?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer