Migration to Dapper

[Alan McKinnon]

On Thursday, 23 February 2006 09:26, Senectus . wrote:
> On 2/23/06, Serg Belokamen <serg.belokamen at gmail.com> wrote:
> > > > * I have not kept track of many additional software on Horay.
> > > > Is there a way to find out which additional software (Java,
> > > > Flash, RealPlayer, Adobe, etc) I have installed so that I can
> > > > install them on Dapper?
> >
> > If you didn't keep track you might be in pain my friend. If
> > however you have a spare machien or a spare HDD, do a virgin
> > install and run updates. This will give you a base system.
> > Then do a dpkg -l > base_system_deb.txt On your real system do
> > the same and then run a diff utility on the two files.
> >
> > If you were refering to compiled packages on the other hand, you
> > should have all of them backed up, maybe in /usr/local/src or
> > something... As you should! Or once again its SOL dude.
> >
> > Don't think this was much help but option #1 could be useful.
>
> There's something that Ubuntu has the opportunity to pioneer and do
> _right_. Find a way to keep track of this information or better yet
> script a way to find out what's been done _after_ the fact.
> I realise this wouldn't be a simple thing to do but if you think
> about it, it's one of those things we really need to get done to
> put us ahead of the Win environment by a large milestone.
>
> Doesn't anyone else think so?

This would be awesomely hard and probably very error prone. I suspect 
it would cause more problems that it would solve. With respect to 
packages the only things a package manager knows for certain are 
things it installed itself - everything else tends to be a monolithic 
block of files and a package manager has no real way of knowing which 
files went with which extra package.

If the user was paying attention in class and installed other programs 
correctly, there are two places to investigate:

/opt for pre-compiled third party stuff. tar the whole directory, and 
tar each dir under /opt to get something that can be restored

/usr/local - the hard one. Especially as it's contents were compiled 
by and against other stuff in / and there's no way to reliably 
recreate the process afterwards to discover how it all came about.

What a script could do is scan /opt and report on the names of dirs it 
finds there. Then scan all binaries in /usr/local checking what libs 
they were compiled against. From this you get a list of other 
packages that must be present for the local stuff to work. At the end 
of all this the user gets a partial list of things to be installed 
manually. The danger is that the average user will treat it as a 
complete 100% accurate list and complain mostly loudly when it 
doesn't all JustWork. And I haven't even considered the mess we find 
inside ~/.wine/drive_c/

There's a good reason why no OS has ever tracked packages outside it's 
own package manager: too little information and it mostly can't be 
done reliably

-- 
Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five