[mythtv-users] FC4: 0.18 ---> 0.19

[Axel Thimm]

On Wed, Feb 22, 2006 at 11:50:02PM -0800, Jarod Wilson wrote:
> On Wednesday 22 February 2006 09:41, Axel Thimm wrote:
> > On Wed, Feb 22, 2006 at 10:08:15AM -0500, Dylan R. Semler wrote:
> > > Axel Thimm wrote:
> > > >On Wed, Feb 22, 2006 at 01:07:20AM -0500, Dylan R. Semler wrote:
> > > >>Just in case it comes up again, the best way i've found to only upgrade
> > > >>the myth package through yum is
> > > >>yum upgrade myth\* --enablerepo=atrpms.
> > > >>This should pick up everything.
> > > >
> > > >No, this is breaking systems, you have neither libmyth in it, nor any
> > > >of the several dozens of myth dependencies.
> > >
> > > Sorry for the misinformation.  Shouldn't yum resolve the dependencies
> > > though?
> >
> > No, it would only do so for missing packages (e.g. a new dependency
> > introduced by the latest mythtv package), not for such that exist, but
> > are outdated.
> 
> To clarify, I'm fairly certain that in the case of only upgrading MythTV, 'yum 
> upgrade myth\*' actually does basically work, if you're moving from one 
> version to another (i.e. 0.18.1 to 0.19), including pulling in the updated 
> libmyth and any new dependencies. However, it won't work if you're moving 
> from say 0.19-120 to 0.19-121 though, as the libmyth dependency of say 
> mythtv-frontend-0.19-121 would already be satisfied by libmyth-0.19-120. One 
> could craft an upgrade line that would also pull in an updated libmyth, but I 
> believe the point Axel is making is that deps on libraries outside of myth 
> itself might also be met by older versions, but to get optimal functionality, 
> you really need the latest ones ATrpms provides, so don't do selective 
> updates.

There are also cases like for libquicktime, where core functionality
has changed w/o the soname bumping up the version. So w/o a complete
upgrade you will be hosted (if you use quicktime somehwere). There are
also similar things happening with almost all software pieces, even
glib/gtk and friends introduce new functions w/o bumbing the major
libversion for ages now.

Their argument is the same as here: They are only backwards compatible
and assume that you will always have upgraded to the glib/gtk version
the rest of the applications have been built against.

It is just the sane thing to do: Upgrade against the whole ensemble,
not a subpart.

> For the pending guide update to FC5, I'm more likely than not going to switch 
> over to smart. While I like the idea of using the distro-provided tool (yum), 
> its still got some issues with its depsolver. I'm hoping that once I'm 
> settled in at Red Hat, I'll be able to spend some work hours on the yum code 
> to help improve it... :)

Or spend some time getting in smart into the Core distribution? I've
looked a bit too often into yum's code, so I know that it's a
Herculian task to fix some things.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-users/attachments/20060223/58da7384/attachment.pgp