On Aug 27, 2009, at 7:40 PM, Robert Milkowski wrote:
More like:
pkgrecv -s <src_repo> -d <dest_repo> --no-deps $1
pkg install pkg://my_publisher/$1
This is not that bad then, especially if -d could be ommited and
default local depo would be used.
sure .. i'd assume that if you're doing this, than you have a
private local repo anyhow .. so why not:
pkg republish -s <src_repo> --no-deps $1
pkg install $1
I like it even more (being a subcommand to pkg rather then utilizing
pkgrecv) - at least for this specific case.
Then once there is an on-disk format I assume it would be possible
to re-publish to it instead to remote repo.
of course it might be bit handy to still have the dependencies
available in the consolidations (eg: entire) but not necessarily in
the individual packages .. i mean - if we're not compiling as part
of the install, who cares what order the packages get installed as
long as they all get there and don't clobber each other?
I'm not sure if I understand what you mean exactly...
well - in the above scenario - what would happen if you did a:
pkg republish -s <src_repo> --no-deps entire
consolidations (like entire, or gcc-dev) are just really packages that
consist of incorporate dependencies - so stripping all depend lines
from these really wouldn't help ..
but if you think of it on another level - since there's no real class
action scripts in package manifests (except for triggering SMF or a
reboot), and package files aren't supposed to collide with other
packages .. why not remove dependencies entirely from the individual
packages, put instead keep them in a consolidation? .. this way when
installing consolidations all you're really doing is laying down files
which means you can optimally write multiple streams in parallel to
reduce install time (could even test the hw or network first to
determine the optimal # of streams) .. then from within the
consolidation you trigger the class action sorts of things, SMF
manipulation, or reboot .. in other words - why not keep the
dependencies separate from the actual file bundles?
this way individual package actions are really just a simple form of a
--no-dep, and your complete supportable bundles are kept intact by
having proper dependency maps between the consolidations
sorry - i must be missing something major here .. IIRC, we had
consolidations before, but over time they simply grew far too big and
became impossible to refactor .. hence (IMH and uneducated read on the
history) ON just became a huge WOS over time and nobody really wanted
to take the time to fight the religion over what should really be
separated from other things.
i dunno .. just another thought
---
.je
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
