up2date problem?
Alexandre Oliva
aoliva at redhat.com
Mon Oct 13 18:37:27 UTC 2003
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
More information about the fedora-test-list
mailing list