[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] Processing of binary IUs
- From: Thomas Hallgren <thomas@xxxxxxx>
- Date: Wed, 26 Jun 2013 23:18:02 +0200
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
On 2013-06-26 15:08, Vladimir Prus wrote:
On 26.06.2013 16:52, Thomas Hallgren wrote:
However, if my case I have local repository already. Copying big files from one local location to another does not
add any more
I would argue that it does. There's nothing that restricts the installation from modifying the file once it has been
installed. If you have
multiple instances, then one instance might corrupt the file from other instances. I.e. the downloaded copy is
immutable, the installed copy
What is 'downloaded copy'. There's the story we have:
- There's local P2 repository, containing a fairly big artifact
- P2 copies that artifact into cache directory and executes touchpoint
I agree that this step is excessive. It shouldn't be needed when the repository is on your local disk.
- touchpoint unzips the artifact (and along the way, makes backup copies of whatever files are replaces)
While I suppose touchpoint can destroy the copy in the cache directory, this does not seem like a very likely
If it does, then something is wrong. The cached copy is not yet installed so it should be considered immutable.
I'm not sure what you mean by the 'installer binary' in this context. But I do agree that it would be very feasible to
unzip using a stream reading directly from the artifact found in a local repository. If there isn't a bugzilla
requesting an improvement for this already, then I suggest you enter one.
I suppose I am not sure why P2 want to make policy decisions that better left to my specific application. In my
case, making a cache copy of a 1GB artifact is simply unnecessary expense. In fact, ideally, I want the unzip
touchpoint to operate on a *stream* that reads data directly from installer binary.