fix scratchbox deployment

RESOLVED INCOMPLETE

Status

P5
normal
RESOLVED INCOMPLETE
8 years ago
5 years ago

People

(Reporter: dustin, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [puppet])

Scratchbox is currently installed via two rpms, which seem to be wrappers around untarring a tarball.  This has a few problems.  The RPM must be downloaded in its entirety before being installed, which doubles the (signficant!) space required.  It's often impossible to install scratchbox on a VM that is not freshly imaged.

We also see repeated re-installs of scratchboxes.  I'm not sure why, but I suspect it has something to do with the Exec[check-scratchbox-install] resource.

Comment 1

8 years ago
We should weigh the downsides of not fixing this against the potential of de-supporting Maemo in the foreseeable future.
It's one of the more difficult forms of slave-wedged to get out of, and also chews bandwidth until it's fixed (since it downloads scratchbox almost continuously, with 60 second pauses between each download).  So I'd like to fix it.
(In reply to comment #1)
> We should weigh the downsides of not fixing this against the potential of
> de-supporting Maemo in the foreseeable future.

Aki: any idea when that might be? Is it tied to a particular version?
Priority: -- → P5
if we do decide to fix it, we need to be very very careful to capture the pre(un)/post(un) logic in the rpm.  Without the special steps, we could easily screw up the entire system.

How often do we have to reinstall?

Updated

7 years ago
Blocks: 701113
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.