how to transfer APT packages between different devices?

[TomRoche]

summary: My old laptop is up-to-date on LMDE, and has many add-on APT packages. I'm now qualifying a new laptop, from a different vendor, on which I have installed LMDE from live USB. How best/easiest to transfer the packages from the first laptop to the second, without causing (e.g.) driver problems? (And please lemme know soonest, since I can't return for refund after 2 Dec 2011.)

details:

I have a 2-year-old laptop (call it "laptop_0") from one vendor. It has served me well, but the battery is shot, the HD makes ominous intermittent clicking noises, it's no longer SOTA, and in any case I could use a backup laptop. This week my university put some quite high-powered laptops on clearance for quite a good price, so I'm evaluating one (call it "laptop_1"). I can return it by Friday for full refund.

I regularly backup my packages on laptop_0 using a script that

* copies /etc/apt/sources.list to a designated backup directory
* copies /etc/apt/sources.list.d/ to the backup directory
* redirects `dpkg --get-selections` to the file in a backup directory

I have in the past restored my packages from laptop_0 to laptop_0 (e.g., after ubuntu upgrades) by the nearly-reverse process:

* restores /etc/apt/sources.list from a designated backup directory
* restores /etc/apt/sources.list.d/ from the backup directory
* redirects the backed-up package list to `dpkg --set-selections`
* apt-get install -y dselect
* dselect update
* apt-get dselect-upgrade
* aptitude update

I installed 64bit LMDE 201109 Gnome from live USB (using unetbootin) on laptop_1 without difficulty. laptop_1 has some problems with LMDE, e.g.,

- it hangs if I try to suspend with a USB drive attached (but it sleeps/restores normally otherwise

- hibernation fails, i.e., instead of restoring it just reboots (but so does laptop_0)

Other than that :-) it seems worth the price, but I've done relatively little testing. To do more a more substantial comparison I need to get roughly the same packages installed on both boxes. Unfortunately there are some substantial differences between the two (though both are 64bit, Intel, and NVIDIA). I noticed this the hard way when I attempted to "restore" (using the second procedure above) the packages from laptop_0 onto laptop_1: it booted, but then put up a crippled GINA (the graphical login screen) into which I could not type (the keyboard was not working, though the mouse was). Fortunately I just rebooted and reinstalled LMDE, which took all of 10 minutes. (One suspects Windows will never install that quickly :-)

So obviously my current package-restore procedure only works to restore, i.e., on the same device from which the packages were backed up. I'm wondering, how can I do package-transfer? I.e., I need a procedure that is smart enough to not transfer inappropriate packages (e.g., those causing driver conflicts). Failing that, I need to know (more-or-less) what not to transfer, so I can edit my package list by hand (before running the package-restore script).

Or something completely different? What do you believe is the best way to transfer packages from one device to another/non-identical device? Please lemme know soonest--I can't return laptop_1 for full refund after 2 Dec 2011.

TIA, Tom Roche <Tom_Roche@pobox.com>

[richyrich]

If you have Synaptic Package Manager, it's easy! Just go to File -> Generate package download script. (hover your mouse over the menu item for a brief description)

[TomRoche]

I'm wondering, how can I do package-transfer? I.e., I need a procedure that is smart enough to not transfer inappropriate packages (e.g., those causing driver conflicts).

If you have Synaptic Package Manager, it's easy! Just go to File -> Generate package download script.

All that does is ... generate a package-download script. Unless I'm missing something, that doesn't even install the packages, much less handle conflicts of the sort described @ top of thread.

[wayne128]

You can consider clone laptop_0 and install that onto laptop_1.

[TomRoche]

there are some substantial differences between the two [laptops] (though both are 64bit, Intel, and NVIDIA). I noticed this the hard way when I attempted to "restore" [...] the packages from laptop_0 onto laptop_1: it booted, but then put up a crippled GINA (the graphical login screen) into which I could not type (the keyboard was not working, though the mouse was).

You can consider clone laptop_0 and install that onto laptop_1.

Umm ... wouldn't that be guaranteed to fail unless they were identical devices? In which case I wouldn't be having this problem: package transfer would be trivial. Or am I missing something?

[richyrich]

Hmmm . . . okay, I don't appreciate the attitude. Last reply.

Generate the script. copy just the script over to the new machine, then in the new machine's same Package Manager menu -> File -> Add downloaded packages, then point it to that script file.

Yes, you will need to download new apps, they will most likely be newer versions and will be compiled specifically for your new machine, and they will also need to be monitored and maintained from your new machine's repositories.

[TomRoche]

I don't appreciate the attitude.

You're inferring the attitude. (It is good to remember that forums, like email, are "like tofu": they take the flavor of their surroundings--which in the case of email and forums is the receiver's emotional state.) The only thing to which I object is, you seem to be missing the point: I already have a package-list-based procedure for transferring packages, but it doesn't cope well with device differences. From top of thread:

I regularly backup my packages on laptop_0 using a script that

* copies /etc/apt/sources.list to a designated backup directory
* copies /etc/apt/sources.list.d/ to the backup directory
* redirects `dpkg --get-selections` to the file in a backup directory

I have in the past restored my packages from laptop_0 to laptop_0 (e.g., after ubuntu upgrades) by the nearly-reverse process:

* restores /etc/apt/sources.list from a designated backup directory
* restores /etc/apt/sources.list.d/ from the backup directory
* redirects the backed-up package list to `dpkg --set-selections`
* apt-get install -y dselect
* dselect update
* apt-get dselect-upgrade
* aptitude update

Note that this automates (using the package list) what your approach does by hand:

Generate the script. copy just the script over to the new machine, then in the new machine's same Package Manager menu -> File -> Add downloaded packages, then point it to that script file.

The raison d'être for tools like apt-get, dpkg, and dselect is to take a package list and a repository list (from, e.g., sources.list) and automate the getting, download, and installation of packages, no?

Furthermore, I don't see how your approach won't suffer from the same problem that mine does:

there are some substantial differences between the two (though both are 64bit, Intel, and NVIDIA). I noticed this the hard way when I attempted to "restore" (using the second procedure above) the packages from laptop_0 onto laptop_1: it booted, but then put up a crippled GINA (the graphical login screen) into which I could not type (the keyboard was not working, though the mouse was). [Instead] I need a procedure that is smart enough to not transfer inappropriate packages (e.g., those causing driver conflicts).

Am I missing something? Will synaptic protect the recipient device from inappropriate packages better than will apt-get, dpkg, and dselect (which IIRC synaptic is using "under the hood" of its GUI)? I'm skeptical, but *that* appears to be the appropriate attitude, given the evidence.

[richyrich]

Apologies, I didn't realize that you don't like, and prefer not to use GUI's.

Synaptic is a graphical package management tool based on GTK+ and APT.
Synaptic enables you to install, upgrade and remove software packages in
a user friendly way.

Besides these basic functions the following features are provided:
* Search and filter the list of available packages
* Perform smart system upgrades
* Fix broken package dependencies
* Edit the list of used repositories (sources.list)
* Download the latest changelog of a package
* Configure packages through the debconf system
* Browse all available documentation related to a package (dwww is required)

good luck,