On Jun 21, 2009, at 1:23 AM, Laurent Blume wrote:
> Shawn Walker a ?crit :
>> In the future, the client will support access to a repository from  
>> the filesystem.  Which means all you need to provide repository  
>> access is an nfs mount :)  The publication tools already support  
>> this.
>> I think you'll agree nfs mounts are pretty common in UNIX server  
>> environments ...
>
> They are, but again, anything needing network access isn't much  
> useful when you don't have network access.
>

Note an nfs mount is just a filesystem, so that implies that anything  
that can provide files works.

> So, doing that from files on a CD is needed. And it has to be  
> individual

Again, filesystem, so a CD, DVD, usb stick, etc. is possible.

> packages. Duplicating a whole repository when only a few packages  
> need to be upgraded is a waste of time, even more when you have to  
> do this for several isolated systems and small network segments.

I think the word repository 'evokes' some sort of image that implies  
an entire collection of software, when that really isn't true.

The version of pkgrecv in the ips source gate right now has the  
ability to extract and republish specific packages from one repository  
to another or create a new one on the fly.

So for example, if you wanted just gcc and its dependencies in a new  
repository on a filesystem:

pkgrecv -s http://pkg.opensolaris.org/dev -d file:///path/to/repo -r  
SUNWgcc

> And there's the obvious case pointed out by HeCSa: what if you need  
> to get an upgrade to have that network connectivity in the first  
> place?
> Copying files by hand, add_drv and such, it doesn't make IPS look so  
> modern :-)

See above.

> Since it's is all new and great, it should rightly take those  
> limitations into account from the start. I've got a feeling that  
> "the network is the computer" has turned into "the computer won't  
> work without a network" :-)


I realise we don't have a roadmap that lays out what all the plans  
are, but off-line support has been a goal from the beginning.  The  
issue has been that resources available to implement all the  
functionality needed is finite, so the most important functionality  
was implemented first.

Delaying an on-disk format has been a significant advantage for us  
since it forced and allowed a refinement of the network-centric  
portions of the design.  Remember that pkg(5) was only just started  
near the end of 2007, so design and implementation have been occurring  
rapidly.

Because of the delay, the on-disk format when it is implemented will  
be much better than it would have been had we attempted one at the  
beginning because other parts of the system have changed.

Cheers,

-- 
Shawn Walker

Reply via email to