Menu
▾
▴
#127 [Patch] Snapshot feature
The attached patch adds a new "snapshot" command to
Fink. Snapshot creates a .info file in
dists/local/main/finkinfo/snapshots. That .info file,
titled "snap-%Y.%M.%D.%H-1.info", is a bundle with a
Depends on every currently-installed package.
The point of this snapshot is that it is a record of
everything you have installed. You can copy the
snapshot to a new computer and "fink build" it, thus
replicating your previous environment (although perhaps
with different versions of the installed packages).
The inspiration for this feature comes from the CPAN.pm
"autobundle" feature, which is a handy way to
encapsulate all of the currently installer Perl modules.
implementation of the snapshot command
Logged In: YES
user_id=286406
Seems to work fine. And i like the feature.
I added a patch that applies to current fink cvs. I also changed the
generated Depends field to use the multi-line format for better readability. I
hope you like it too.
this applies to fink cvs. Mulitline Depends field.
Logged In: YES
user_id=535292
Cool idea!
We finally got around to documenting the %commands table, so
according to:
# The list of commands. Maps command names to a list
containing
# a function reference, and three flags. The first flag
indicates
# whether this command requires the package descriptions to be
# read, the second flag whether root permissions are
needed the
# third flag whether apt-get might be called if the
UseBinaryDist
# option is enabled. 1, if apt-get is called without the
# '--ignore-breakage' option, 2, if it is called with
'--ignore-breakage'
you'd want the first to be "1". That would mean you can
eliminate the call to require_packages().
In principle this could run as root or non-root. If it is
first run as root, however, $snapdir will be owned by root
and only writable by root. That would mean all future runs
could only be performed by root. By the same logic, if it's
first run as non-root, only root or that first-run user can
run it. You could make $snapdir world-writable, but that
means anyone who can log in can insert a:
Package: fink
Version: 1.0
CompileScript: rm -rf /
into your package tree, just waiting for you to 'fink
selfupdate'. Maybe better to restrict this mode to root: set
the second flag to "1".
Looking at the timestamp used in the package name, why not
include the minutes? Also, formatting it with a hyphen
between the date and time components would make it easier to
read. The buildlock system uses:
$timestamp = strftime "%Y.%m.%d-%H.%M.%S", localtime;
"snap" seems like a pretty generic name, apt to be used by
some "real" package. "fink-snapshot" would be more
descriptive and unique.
How are (and how should) virtual packages be handled? What
if the currently installed foo Provides:bar, but the foo
available when reconstituting the snapshot does not? What
about VirtPackage (system placeholder) packages?
Logged In: YES
user_id=50365
Attached v3 patch.
Regarding Daniel's points:
* require_packages: 1 -- done
* root -- that's disappointing, but I agree with your
analysis. I changed it to just install in /tmp. After all,
this file is meant to be carried to other computers, not
installed locally.
* timestamp -- I emulated CPAN.pm, which does YMDH. Once
per hour *should* be enough for anyone, yes? I changed it
to use strftime
* I changed the package name to "fink-snapshot"
* I now omit virtual packages (meant to do that the first
time, but forgot). On a new machine, Fink will presumably
prompt for packages to satisfy the virtual dependencies.
Additionally, I made edits to the man page, and added brief
instructions for what to do with the output file after it is
built.
updated with input from dmacks, chris01
Logged In: YES
user_id=535292
*root: If the resulting .info is not going to be in a place
where fink will automatically see it, I don't think it
matters whether the .info generation is run as root or not.
* timestamp: up to you really.
* docs: excellent!
* This thing is gonna wreak havoc with debfoster.
Logged In: YES
user_id=50365
dmacks wrote:
> This thing is gonna wreak havoc with debfoster.
Hmm, I skipped that thread on fink-devel, so I really know
nothing about it. Is this something I should worry about?
Or should I let the debfoster people figure out the details?
Aside from that, should I CVS commit this patch myself?
Should I ask for comments on fink-devel first?
Thanks!
Logged In: YES
user_id=286406
chris: i tried your latest patch. And it seems to work fine here.
The only problem i found: 'man fink' gives:
show-deps package...
Displays a human-readable list of the compile-time (build) and run-
time (installation) dependencies of the listed package(s).
Creates a file detailing all of your installed packages. You can move
this file to a new computer, install it with Fink there, and your whole
Fink environment will be replicated.
Logged In: YES
user_id=50365
Thanks for the feedback guys. I fixed the man page error
(and learned something about writing man pages in the
process) and I will commit the changes momentarily.