[mythtv-users] Mythbackend Segfault on Delete SOLVED!!

Jarod Wilson lists at wilsonet.com
Wed Jan 24 18:41:59 UTC 2007


Axel Thimm wrote:
> 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"? :/

I thought it was relegated to the tips and tricks page, but I just took 
a peek, and it actually is in the main 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
> <regex>'s dependencies.

Not if they're already satisfied, no.

> So if foo was built against bar and both get an update, yum upgrade
> *foo* will not pull in bar.

Ideally, if the updated foo *requires* the updated bar to run, there'd 
be some sort of dep between them so the updated bar *would* get pulled 
in, but I realize that's a pipe dream...

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

AFAIK too.

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

:D

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

Point taken.

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

Requires: a52dec >= ? :)

Okay, so that could get ugly... Esp. if there were multiple repositories 
that had a52dec in some form or another and a user mixed-n-matched...

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

However, regardless of the selective/partial upgrade issues, it would 
seem to be more technically correct to have mythtv-frontend and 
mythtv-backend rely on the exact matching libmyth.

>> I don't want to do a full yum upgrade every time I want just a few
>> updated packages...
> 
> Why not?

Take my libdv/dvgrab example from above. All I wanted was those bits 
from updates-testing. I wanted to stick with the formally released bits 
for everything else. Some folks also simply want to upgrade as little as 
possible, either for fear of breaking something or for bandwidth 
considerations (what!?! not everyone has a fiber pipe to their house 
like I do?!? :).

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

Heh, okay, okay, I'll make some changes...

--jarod


More information about the mythtv-users mailing list