[mythtv-users] Mythbackend Segfault on Delete SOLVED!!
Axel.Thimm at ATrpms.net
Wed Jan 24 15:30:24 UTC 2007
On Wed, Jan 24, 2007 at 10:06:22AM -0500, Jarod Wilson wrote:
> Axel Thimm wrote:
> > On Mon, Jan 22, 2007 at 03:08:43PM -0800, Kirk Bocek wrote:
> >> My problem was a libmyth package that was older than the
> >> mythbackend package. I was accidentally entering 'yum update
> >> myth\*' to update instead of 'yum update \*myth\*' when updating
> >> from atrpms.
> >> Hey, Axel, I thought yum was supposed to at least warn about dependencies like
> >> this?
> > Please imagine the next line in loud capital letters:
> > don't use selective/partial upgrading. you - are - on - your - own!
> > On even larger letters:
> > don't even bug packagers and upstream about that! you - created - this
> > - bug!
> > And in largest fonts, blinking in red
> > go after the people advising to do so, find them and kill them
> I think you just put out a hit on me. :)
Oops, that was not intented, I hope I can call off the hit in time ;)
But where do you do such sinful things? Not on "The Guide"? :/
> > If the above sounds harsh, it's for educational purposes. If you don't
> > know the background just google for partial and/or selective upgrades.
> That holds more for having a repo disabled, but pulling in select
> packages, I thought. With the repo enabled and a request to upgrade only
> certain components, things really ought to work just fine.
It doesn't matter to yum, whether the enabling is temporary (through
--enablerepo) or steady, yum install <regex> will not update the
So if foo was built against bar and both get an update, yum upgrade
*foo* will not pull in bar.
Iff yum would have something like yum upgraderecursive blah, then that
would be a different story, e.g. a yum upgraderecursive mythtv-suite
would be enough, no myth*, *myth* etc trickery. But neither yum, nor
any other competitor has this ability (AFAIK, glad to be proven
> I do this all the time w/o problem... For example, I only wanted to
> upgrade to libdv and dvgrab out of fedora updates-testing yesterday,
> so I did a 'yum upgrade libdv\* dvgrab'.
That's because you successfully outsource part of the depsolver's
mechanism to your brain ;)
A typical user would probably not care about (or simply miss) libdv
and only try to upgrade dvgrab and possibly fall into the same issue.
> Its always worked for me for myth package upgrades as well, as long
> as its \*myth\* and not myth\*.
and what if a fix/required update is in one of the following,
e.g. fftw or a52dec? Any kind of selective/partial upgrade will miss
something in the complex build dependencies like mythtv's, and not
only those from ATrpms, but from Core and Extras as well. The API/ABI
change in both Core and much more in Extras.
| GConf2 Glide3 Glide3-libGL ImageMagick MAKEDEV ORBit2 SDL SDL-devel
| SysVinit a52dec-devel alsa-lib-devel arts arts-devel aspell aspell-en
| atk audiofile audiofile-devel audit-libs-python avahi avahi-devel
| avahi-glib avahi-qt3 bzip2-devel cairo cdparanoia-devel
| cdparanoia-libs chkfontpath cryptsetup-luks cups-libs cyrus-sasl-lib
| dbus dbus-glib dbus-python desktop-backgrounds-basic
| desktop-file-utils dmidecode e2fsprogs-devel esound esound-devel
| faac-devel faad2 faad2-devel fedora-logos fftw2 fftw2-devel
| fftw2-double fftw2-double-devel fftw2-single fftw2-single-devel flac
| flac-devel fontconfig fontconfig-devel freetype freetype-devel gamin
| gcc-c++ gd ghostscript ghostscript-fonts glib glib2 glib2-devel
| gnome-keyring gnome-mime-data gnome-mount gnome-vfs2 gnutls gtk+ gtk2
| gtk2-engines hal hicolor-icon-theme hwdata jack-audio-connection-kit
| jack-audio-connection-kit-devel kbd kdelibs kdelibs-devel kdnssd-avahi
| kdnssd-avahi-devel krb5-devel lame-devel lcms libFS libICE
| libICE-devel libIDL libSM libSM-devel libX11 libX11-devel libXTrap
| libXau libXau-devel libXaw libXcursor libXcursor-devel libXdmcp
| libXdmcp-devel libXext libXext-devel libXfixes libXfont libXfontcache
| libXft libXft-devel libXi libXinerama libXinerama-devel libXmu
| libXmu-devel libXpm libXrandr libXrandr-devel libXrender
| libXrender-devel libXres libXt libXt-devel libXv libXv-devel libXvMC
| libXvMC-devel libXvMCW-devel libXxf86misc libXxf86vm libXxf86vm-devel
| liba52_0 libacl-devel libart_lgpl libart_lgpl-devel libasound2
| libattr-devel libavc1394 libavc1394-devel libavcodec51 libavutil49
| libbonobo libbonoboui libcdaudio libcdaudio-devel libcroco libdaemon
| libdca libdrm libdv libdvdcss libdvdcss-devel libdvdnav-devel
| libdvdnav4 libdvdread libdvdread-devel libexif libexif-devel libfaac0
| libfame libfame-devel libfontenc libfreebob libgcrypt libgcrypt-devel
| libgcrypt11 libglade2 libgnome libgnomecanvas libgnomeui libgpg-error
| libgpg-error-devel libgsf libid3tag libid3tag-devel libidn
| libidn-devel libiec61883 libiec61883-devel libjpeg libjpeg-devel
| liblzo1 libmad-devel libmad0 libmng libmng-devel libmp3lame0
| libmp4v2_0 libmpeg2_0 libmpeg2convert0 libnotify libogg libogg-devel
| libpng libpng-devel libquicktime0 libraw1394 libraw1394-devel librsvg2
| libselinux libselinux-python libsemanage libstdc++-devel libsysfs
| libtermcap-devel libtheora libtheora-devel libtiff libtiff-devel
| libusb libuser libutempter libvolume_id libvorbis libvorbis-devel
| libwmf libwnck libx264_54 libx264gtk54 libxml2 libxml2-devel
| libxml2-python libxslt libxslt-devel libxvidcore4 lirc-lib
| lirc-lib-devel lm_sensors lm_sensors-devel mesa-libGL mesa-libGL-devel
| mesa-libGLU mesa-libGLU-devel mjpegtools mjpegtools-devel
| module-init-tools mysql mysql-devel nasm notification-daemon openldap
| openssl-devel pango passwd pciutils pcre-devel perl-DBI pkgconfig
| pm-utils policycoreutils qt qt-devel redhat-artwork redhat-menus
| shared-mime-info startup-notification transcode ttmkfdir udev
| urw-fonts usermode util-linux video4linux-devel x264-devel
| xorg-x11-filesystem xorg-x11-font-utils xorg-x11-proto-devel
| xorg-x11-server-utils xorg-x11-util-macros xorg-x11-xfs xvidcore-devel
> But in thinking about it, why not have a full e-v-r dep in
> mythtv-backend and/or mythtv-frontend on libmyth?
That would only pretend solving the general issue of selective/partial
upgrades for a single case.
> I don't want to do a full yum upgrade every time I want just a few
> updated packages...
Why not? The updates are there for several reasons, most important are
security updates - therefore the default for a typical user should be
to always upgrade unless He Really Knows What He's Doing (TM). The
latter applies to you (Jarod), of course, but you cannot assume that
all users are as good at depsolving as your brain is. ;)
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-users/attachments/20070124/95c5ab73/attachment.pgp
More information about the mythtv-users