Spec suggestion : dependancies with a non-networked computer

Peter Whittaker pwwnow at gmail.com
Mon Mar 6 20:10:32 GMT 2006


Sean Hammond wrote:
> 
> The only weakness of this solution, it seems, is that Alice 
> must use synaptic on her non-connected computer first to 
> create the script which she takes to the connected machine. 
> On Windows, you just go straight to the connected machine and 
> download the .exe.

It depends on your perspective: As noted by another poster, the two
users might be starting from very different places, so downloading on
the connected machine and bundling the package and all dependencies onto
a medium accessible by the non-connected machine may create a far larger
package than necessary (as much or more than a complete distro
release!).

Personally, I really like the two-pass option, and it is what I would
have suggested had it not already existed: Run a tool to create the
script that can run elsewhere and itself create just what I need to get
what I want.

But then again, I am a relatively technical user and I tend to think
along these lines: Little, logical steps, clean,
high-probability-of-success approaches...

> If synaptic had a 'create offline installer' capability where 
> it would assume a default Ubuntu install and download all 
> the.deb's needed to install some package, then you wouldn't 
> need to export a script from the non-connected machine first, 
> but you might end up downloading more .deb's than you really had to.

...but one really needs to support both. For the motivated
planning-oriented user, support the way of working described above and
implemented in Synaptic. Keeps me happy, 'cause I get exactly what I
need, don't have extra baggage, etc. The nice thing about this approach
is that if the user works this way, what they run on their machine the
second time will do exactly what they expected: Install the desired
package.

For the "just do it, darn it all, I want it to be easy" user, the
approach Sean suggests is needed: Create a package on a connected
machine that will cause the desired package to be installed on the first
machine. That way, users who "just want it" can have some hope of
getting what they need.

Trouble is, how different are the starting points? Are they both Breezy?
Both Dapper? Dapper+1? Dapper with daily updates? Different distros
altogether? How much intelligence does the packaging utility need to
account for differences between the two systems and make it so that the
"just run it once" user gets what they wanted and not a heap of
frustration.

Personally, I think Synaptic is going in the right direction doing the
two-pass approach first: It is the technically easier to implement, with
simpler use cases and a higher probability of "just working".

The approach Sean suggests needs more use cases, with some
straight-forward 80/20 logic: What can be done to handle most cases with
relatively simple and robust logic? That's the 20% effort that will
cover the 80% of cases (assume same distro, e.g.). THEN - and this is
the tricky part - what are the exceptions, and how can they be handled
with robust "as simple as possible but no simpler than necessary" logic?

Takers?

pww




More information about the ubuntu-devel mailing list