[KLUG Members] Re: problem with updates on Ubuntu 7.1

Mike Williams knightperson at zuzax.com
Thu Jul 10 21:34:16 EDT 2008


Robert G. Brown wrote:
> I have seen what Brock originally described on several occasions, and it
> is a byproduct of the sorts of update tools that have come into common
> use.
>
> Most of the tools (rpm, YaST, etc.) pack up the software needed for the
> update, scripts to actually do the install, and a statemnt of some rules,
> mostly about what is needed on the system prior to being able to install
> the package in question.
>
> Let's say that you don't do an update for a while. In the meantime, the
> developers have been real busy, and cumulatively, they didn't write only 1
> new version of the package in question, but 2. Also, the very newest
> version requires 2 libraries, and the upgrade of a third.
>
> Now the update process starts. A lot of these "repositories" determine the
> number of updates needed when your system queries the repository database,
> in essence saying (given what I have on the system here), what updates are
> available? The repository essentially determines how many updates are
> needed to update the SOFTWARE YOU HAVE RIGHT NOW (not shouting, this is an
> important point to remember).
>
> So you download and install all of those updates. afterall of that dust
> settles, someone (you, the update manager process) eventually gets around
> to doing another database query. Because you have changed the software on
> your system, you may now be eligible for MORE updates than before! How
> can this be?
>
> When this all started, let's say you had a package called "A", and it's
> version 2.3.4. The repository query says there is an upgrade available,
> "A" version 2.3.6. So your update got and installed "A" 2.3.6. the next
> query shows that "A" version 2.4.0 is available (but it required 2.3.6 to
> be installed, 2.3.4 was not "good enough"). Also, 2.4.0 requires the
> "Flivver"and the "Blabber" libraries (to process "Flivver" Image formats
> and "Blabber" audio files, of course), so "A" can show this stuff to the
> user. Thus your inital update showed 1 update available ("A" 2.3.4 to "A"
> 2.3.6) and the second update shows THREE updates ("A" 2.3.6 -> 2.4.0, and
> libflivver AND libblabber). This can go on for several levels if you wait
> long enough to do updates, but persisting with the process ought to catch
> you up.
>   
Gentoo's Portage system, which I think was adapted from BSD, gets around 
that problem.  It downloads source packages and compiles them, compiling 
in options based on "use flags" that you set in a config file.  An 
update takes longer since it has to compile everything, but the final 
code is smaller and more efficient than generic binaries.  There are a 
couple ways of launching the update process.  A regular "update world", 
which behaves just like you described above, and an "update world deep" 
that gets the newest version of everything it can find plus any oher 
packages required by the updated versions.  For reasons I don't fully 
understand, you have to run a "revdep-rebuild" to handle reverse 
dependencies (whatever those are) after you do a deep update.  I think 
that process handles rebuilding package A if "Flivver" or "Blabber" were 
updated.



More information about the Members mailing list