It would be very nice, especially when using Debian unstable, for
apt-get to be able to automagically save the installed copy of packages
it intends to upgrade or remove.  Invoking 'dpkg-repack' on the list of
packages that will be upgraded or removed, while not perfect, would be
a good start.

If this capability already exists, it might be nice to document it
as an example somewhere in the apt-get man page.

reassign 85960 dpkg-repack
thanks

apt's hook facility already provides all of the information necessary to do
this, so a script could be written for dpkg-repack to repack packages before
they are changed.

Not that I think this would be a particularly good idea, but it should be
possible without any changes to apt, so I'm reassigning this bug.

Indeed, I did that (not knowing of this bug) for myself some weeks ago.

I'll clean it up a bit within the next few days, and I'll send it to this
bug for starters. We can see what to do with it next.

It makes an install run _a lot_ longer, and it takes quite an amount of
disk space if you run unstable and re-pack packages consistently.

OTOH, it does provide for very primitive dpkg rollback functionality,
though it's far from failproof - while I haven't actually tried rolling
back, there will most likely be issues with packages who fail downgrading,
and it is also bound to not work in cases where package install scripts
horribly broke your system. But it's a start.


Regards,

Filip

Indeed, I did that (not knowing of this bug) for myself some weeks ago.

I'll clean it up a bit within the next few days, and I'll send it to this
bug for starters. We can see what to do with it next.

It makes an install run _a lot_ longer, and it takes quite an amount of
disk space if you run unstable and re-pack packages consistently.

OTOH, it does provide for very primitive dpkg rollback functionality,
though it's far from failproof - while I haven't actually tried rolling
back, there will most likely be issues with packages who fail downgrading,
and it is also bound to not work in cases where package install scripts
horribly broke your system. But it's a start.


Regards,

Filip

Good to see this is being worked on now ;-)
[...]

Like localepurge, this is a hack, but a useful one in the hands of
someone with appropriate expectations.

The theory is that after some short time period (after using the new
package for a few days, or perhaps after the next reboot) you can figure
out that you won't need the repacked old package file after all, and
delete it.  You would only use disk space proportional to the packages
you upgraded for the time you spent testing the new packages.

The other way to do this is to keep the downloaded Debian packages in
/var/cache/apt/archives until the next release of that package, which
may be tomorrow, next week, next year, or never.  This requires disk
space proportional to the size of all packages installed on the system,
and you can't ever delete anything because you don't know if the packages
might suddenly become unavailable (especially with unofficial apt sources,
with tend to disappear without warning).

Doing dpkg-repack on upgraded packages uses a much lower disk_space *
time product.  This is a big win on laptops where local disk space
is expensive and there might not be a big nearby file server to cache
the downloaded packages.

I wonder if the dpkg-repack-aging could be done in parallel with
downloading new packages?  On a slow net feed with a fast CPU the download
time can be much longer than the repack time.

Note that downgrading an official, non-repacked Debian package by e.g.
'apt-get install foo/stable' has many of the same problems as installing
a dpkg-repacked one.

I've done the dpkg-repack-rollback by hand a number of times, especially
with critical packages that have a history of problems.  It's by no
means foolproof, but usually all that is required to fix the breakage
is renaming a few .dpkg-old files or patching maintainer scripts, or
perhaps toss out some state files.

Even a half-broken package on the local system is better than nothing
in many cases--as a last resort, the package contents could be extracted
with dpkg-deb -x just to get the system working well enough to install a
proper solution.  I've lost count of the number of times I've found myself
with a laptop that lost network connectivity due to post-dist-upgrade
breakage, e.g. because some kernel modules were uninstalled, or because
the latest version of the network configuration utilities don't support
IPV4.

Good to see this is being worked on now ;-)
[...]

Like localepurge, this is a hack, but a useful one in the hands of
someone with appropriate expectations.

The theory is that after some short time period (after using the new
package for a few days, or perhaps after the next reboot) you can figure
out that you won't need the repacked old package file after all, and
delete it.  You would only use disk space proportional to the packages
you upgraded for the time you spent testing the new packages.

The other way to do this is to keep the downloaded Debian packages in
/var/cache/apt/archives until the next release of that package, which
may be tomorrow, next week, next year, or never.  This requires disk
space proportional to the size of all packages installed on the system,
and you can't ever delete anything because you don't know if the packages
might suddenly become unavailable (especially with unofficial apt sources,
with tend to disappear without warning).

Doing dpkg-repack on upgraded packages uses a much lower disk_space *
time product.  This is a big win on laptops where local disk space
is expensive and there might not be a big nearby file server to cache
the downloaded packages.

I wonder if the dpkg-repack-aging could be done in parallel with
downloading new packages?  On a slow net feed with a fast CPU the download
time can be much longer than the repack time.

Note that downgrading an official, non-repacked Debian package by e.g.
'apt-get install foo/stable' has many of the same problems as installing
a dpkg-repacked one.

I've done the dpkg-repack-rollback by hand a number of times, especially
with critical packages that have a history of problems.  It's by no
means foolproof, but usually all that is required to fix the breakage
is renaming a few .dpkg-old files or patching maintainer scripts, or
perhaps toss out some state files.

Even a half-broken package on the local system is better than nothing
in many cases--as a last resort, the package contents could be extracted
with dpkg-deb -x just to get the system working well enough to install a
proper solution.  I've lost count of the number of times I've found myself
with a laptop that lost network connectivity due to post-dist-upgrade
breakage, e.g. because some kernel modules were uninstalled, or because
the latest version of the network configuration utilities don't support
IPV4.

Good to see this is being worked on now ;-)
[...]

Like localepurge, this is a hack, but a useful one in the hands of
someone with appropriate expectations.

The theory is that after some short time period (after using the new
package for a few days, or perhaps after the next reboot) you can figure
out that you won't need the repacked old package file after all, and
delete it.  You would only use disk space proportional to the packages
you upgraded for the time you spent testing the new packages.

The other way to do this is to keep the downloaded Debian packages in
/var/cache/apt/archives until the next release of that package, which
may be tomorrow, next week, next year, or never.  This requires disk
space proportional to the size of all packages installed on the system,
and you can't ever delete anything because you don't know if the packages
might suddenly become unavailable (especially with unofficial apt sources,
with tend to disappear without warning).

Doing dpkg-repack on upgraded packages uses a much lower disk_space *
time product.  This is a big win on laptops where local disk space
is expensive and there might not be a big nearby file server to cache
the downloaded packages.

I wonder if the dpkg-repack-aging could be done in parallel with
downloading new packages?  On a slow net feed with a fast CPU the download
time can be much longer than the repack time.

Note that downgrading an official, non-repacked Debian package by e.g.
'apt-get install foo/stable' has many of the same problems as installing
a dpkg-repacked one.

I've done the dpkg-repack-rollback by hand a number of times, especially
with critical packages that have a history of problems.  It's by no
means foolproof, but usually all that is required to fix the breakage
is renaming a few .dpkg-old files or patching maintainer scripts, or
perhaps toss out some state files.

Even a half-broken package on the local system is better than nothing
in many cases--as a last resort, the package contents could be extracted
with dpkg-deb -x just to get the system working well enough to install a
proper solution.  I've lost count of the number of times I've found myself
with a laptop that lost network connectivity due to post-dist-upgrade
breakage, e.g. because some kernel modules were uninstalled, or because
the latest version of the network configuration utilities don't support
IPV4.

Some time ago you proimised to send your script to integrate dpkg-repack
with apt-get, but I never received it.

Attached here.

It's a 10-minute hack, but good enough for me.
Deal with it as you see fit.

One nice thing not listed in the FIXME/TODO would be a (configurable) way
to list & mark which packages to back up. Perhaps with help of debconf?
Dunno if debconf (c|sh)ould be used within another apt pre-install hook...


Regards,

Filip

Hi,

I run a small Linux course at our university and regularly have the students
write this script as an exercise in shell scripting:

#!/bin/sh
#
# creates subdir and dpkg-repacks all relevant packages in it
#
DIR=$(date +%Y%m%d)
mkdir $DIR
cd $DIR || exit 1
for i in $(echo n | apt-get -u dist-upgrade 2>&1 | grep '^[[:space:]]' | tr -d '*'); do
	ls | grep -q ${i}_ || dpkg-repack $i
done

It's practically a one-liner and doesn't even need apt hooks. (Obviously it
also lacks any pretense of sophistication.)

I'm sending you this in the hope someone else also finds it useful. I use it
routinely.

Andras

Hi.

Anything new here? Especially for >= sid users, this seems to be quite
handy, since it happens every now and then, that packages severely break
things which one only notices after they've migrated to testing...
subsequently downgrading is a bit problematic, even when considering
snapshot.d.o.

A nice feature would perhaps be an option that, if enabled, asks the
user before running, whether all, some or no packages should be
repacked. If the option isn't given, all packages (to be upgraded) are
repacked by default.


Cheers,
Chris.

Guten Tag 85960,

Vermittlungsagentur stellt Ihnen folgende attraktive Arbeitsstelle in einem erfolgreichen Team von zu Hause aus vor, ohne Fahrtkosten, ohne Anfahrt, ohne Stau. Wir generieren qualitative und attraktive Jobs nicht nur in der Stadt, sondern auch in ländlichen Regionen europaweit und bieten dabei hervorragende Qualität für unsere Auftraggeber.
Ab sofort sind nachfolgende Stellen frei:
Mitarbeiter (m/w) für den Support im Home Office im Bereich Telekommunikation und Büroarbeit

Wir bieten Ihnen einen Arbeitsplatz als Festangestellter oder als Gewerbetreibender mit einem Stundenlohn von 20 € pro Stunde in eigenverantwortlichen Arbeitsweise und einer familienfreunflichen Beschäftigungsform, sowie eine spannende Tätigkeit ohne Fahrzeit mit flexiblen Arbeitszeiten.
Es werden keine fachlichen Kenntnisse vorausgesetzt. Die Einarbeitung findet schrittweise durch professionelle Kollegen statt. Die benötigte technische Ausrüstung stellen wir Ihnen ohne weitere Kosten zur Verfügung. Die Beschäftigung kann sogar nebenberuflich besetzt werden, sowie von Rentnern und Hausfrauen.

Was von Ihnen erwartet wird:

- Unproblematischer Umgang mit Email, PC und Internet
- Deutsch fließend, Fremdsprachen wären vorteilhaft
- Zielstrebigkeit und Pünktlichkeit

Ihre Tätigkeitsschwerpunkte sind:

- Unterlagen engegennehmen, bearbeiten und weitersenden
- Dokumente kopieren/einscannen
- Emails bearbeiten
- Tätigkeit im Home Office in freier Zeiteinteilung
- Arbeit mit zur Verfügung gestellten Büroausstattungen

Sie sind offen für flexible Arbeit und die Arbeit im Home Office? Wenn wir Ihr Interesse geweckt haben, senden Sie uns Ihre Bewerbung per E-Mail an: MERVIN1328@elvisfan.com
Wir freuen uns auf Ihre Bewerbung, Ihre persönlichen Unterlagen behandeln wir selbstverständlich vertraulich.

Es grüßt Sie Ihre

Schumacher AG