Prevu deletes downloaded files, even if it has failed
Brought to you by:
jdong2002
Menu
▾
▴
#7 Prevu deletes downloaded files, even if it has failed
I've been trying to build the latest open-office. Prevu
helpfully downloads about 300MB of tarball, and then starts the process of checking dependencies. When it fails (in my case, at dmake), prevu exits, but not before cleaning up, and *deleting the downloaded tarballs*.
I then successfully built and installed dmake using prevu, and returned to my attempt on openoffice. Prevu had to download the tarball again!
[And actually, yet again, since the build failed Total of 1GB downloaded over my poor DSL line].
What I suggest is that prevu should only delete the source tarballs if the build has succeeded! Otherwise, they should be left in place.
So, how to clean up? Obviously, we don't want these files in /var/cache for ever. Why not check the timestamp on files in /var/cache/prevu, and only delete if they are more than 2 days old?
Logged In: YES
user_id=736418
Originator: NO
This is intended behavior that when prevu is directly invoked, it will remove build files regardless of success or failure.
If you intend that you'd need to build a package more than once, manually 'apt-get source' it to a location of your choosing, then issue "prevu" while inside the extracted sources. Prevu will make a copy of your source directory and not touch the original at all.
I'd rather not have a timestamp checker because not everyone will want the same build/unbuild times (my prevu directory is mounted on tmpfs, so everything extracted is using my RAM) and it adds a time-consuming timestamp checker to every prevu operation.
Logged In: YES
user_id=740575
Originator: YES
Thanks for your reply. That said, it does seem a bit odd.
* Since prevu doesn't resolve dependencies, one must manually fix them after the build fails.
* Therefore one would expect a typical build to fail about 2-6 times before it succeeds.
* Why repeat the downloads?
-> Perhaps if prevu fails because of a dependency, it should offer (interactively) to start a subshell, run another instance of prevu and get/install the dependency; then return to the main version.)
Lastly, I'm only suggesting that the timestamps on downloaded tarballs should be checked. i.e. prevu would do this:
1)Download source tarballs, and begin the build.
2)If the build succeeds, delete the source tarball. If the build failed, do NOT delete the tarball.
3)Exit
4)The next time prevu starts, do some housekeeping: delete any source tarballs that are older than a couple of days.
BTW, I was using this documentation: http://ubuntuforums.org/showthread.php?t=268687 - so if it is inaccurate, maybe I could request that you write a definitive backports howto for the wiki. I'd hoped for a really easy way to make my own backports :-)
P.S. When re-reading this, I wonder if I was unclear in my original report. I'm not talking about files which are generated or extracted during the build process. I'm referring to the 300MB tarball that prevu automatically downloads from the deb-src repository.
Logged In: YES
user_id=736418
Originator: NO
The source tarball and extracted source tree are kept together in /var/cache/prevu/src/[process_id].[numeral], and right now they are deleted together.
Spawning a subshell of prevu is not really feasible upon build failure because remember that upon building a build dependency, one must run prevu-update to make the base tarball again, and thus make prevu aware of the new packages.
And it's not typical to have to run prevu "2-6" times. Majority of the backports I do require 1 invocation, and some require 2.
Openoffice is a very unique situation where it's a gigantic source archive that sucks to be downloaded again and again. In that case, download it once manually into your own directory and issue prevu from there, so it doesn't keep re-downloading.
Logged In: YES
user_id=740575
Originator: YES
> Spawning a subshell of prevu is not really feasible upon build failure
> because remember that upon building a build dependency, one must run
> prevu-update to make the base tarball again, and thus make prevu aware of
> the new packages.
Agreed. I didn't literally mean what I actually said (!) What I was really driving at was some sort of dependency resolution (like apt-get does, and like rpm doesn't). So, if a build has failed, prevu should go off and fix the dependency, then resume where it was. It would be a really fabulous feature, because then prevu would be able to do most things automatically. [It could even be added into synaptic :-) ]
> Openoffice is a very unique situation where it's a gigantic source archive
> that sucks to be downloaded again and again. In that case, download it once
> manually into your own directory and issue prevu from there, so it doesn't
> keep re-downloading.
Will do. In the meantime, perhaps some sort of error message to this effect would be helpful.
Also, I've just thought of another possible work-around which would helps interactive users:
Rather than delete with rm, put the tarball into the user's trash directory (~/.local/share/Trash/files) and print an error message.
Best wishes,
Richard
Logged In: YES
user_id=736418
Originator: NO
Yeah, it'd be kinda nice if prevu can intelligently parse pbuilder-satisfydepends.pl output to identify what packages need backporting :)
This problem I also think needs to be solved in documentation. Prevu really needs some decent documentation rather than a forum post here and there, and a 5-line usage printout on syntax error.
Moving to the user's trash is not that ideal either; my home directories are on a different filesystem than prevu; I'd rather not be copying back and forth a bunch of data, especially since it's difficult for a user to re-use those tarballs (prevu will not reuse any of that; it's not like an APT cache....)
Yes, the system is ugly, but in the end unfortunately that's what happens when you try to target a different end-audience with tools designed to be used by Debian/Ubuntu package developers :(