Shawn Walker wrote:
Tom Mueller wrote:
I'm not yet sure if having the concept of a "stream" makes this
easier to explain than just talking about "repositories".
Having the concept of streams allows users to largely be unaware of
the existence of repositories.
Is "largely unaware" actually "completely unaware"? If not, what are
the situations were a user would need to know about an repository. If
yes, then the term "repository" is really going away because users never
know about it. So all we have is publishers, streams and depots. And
if that is the case, we could substitute the word "repository" for
"stream" here because people know what a repository is, but they don't
know what a stream is and we don't need the word stream.
My real question here is whether "stream" and "repository" are really
two concepts or not.
It also allows you to have a single repository for multiple streams.
Can you give an example of this?
And in this example, how are the repositories and streams identified on
the network? Brock said that streams are not identified by URLs. But
at some point, the pkg(1) client needs to make an HTTP request to a URL
to get the package. So there has to be a URL at some point, even if
that is hidden from the user.
The current concept of trying to limit which software train is used
based on repository has been a constant issue for our users in the
past. I can't count how many systems now where the user has had both
the /release and /dev repositories configured under separate
publishers and was switching between them to determine the software
train to use.
I agree that having multiple "streams/repositories" configured as part
of a publisher and providing that information to the client in meta
data, so that users don't manually configure "streams/repositories" by
hand is a good idea.
I'd also add that having the concept of streams is a necessity if we
ever want to get to the point where the ON 'release train' of packages
can be mixed with JDS 'dev train' of packages.
This is also important when you consider client-side caching or an
on-disk format where multiple packages from different publishers and
repositories can live in the same repository.
This last statement may have explained it for me.
Is a "repository" just the file system container for a set of packages?
And a "stream" is a logical presentation (usually presented by a depot,
but could be accessed directly from the distk) of a set of packages that
work together?
Here's a picture:
image 1 image 2
| |
pkg(1) pkg(1)
| / \
dev-stream release-stream update-stream
\ / |
pkg.depotd |
| |
repository on-disk-repository
This is a hypothetical case where the dev and release streams are hosted
in the same repository and that an on-disk format of the future exists
to deliver and update stream.
If this is a correct understanding, would it be also be correct that
with this proposal, bug 7653 need to be changed to talk about streams
rather than repositories?
One of the goals with 7653 is that we can do the following:
Given a set of packages A, B, C, D, and E in a repository. Product X
requires packages A, B, and E and product Y requires packages C, D, and
E. When managing product X in user image, we don't want the user to see
packages C and D. Same for managing product Y (don't want to see A and
B). Currently, we need to create two repositories with two pkg.depotd
processes, and have a copy of package E in both. With 7653 implemented,
we could have one repository with all 5 packages, and then have 2
streams, one for each product.
Regards,
Tom
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
