Tom Mueller (plain-text) wrote:
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
It should be limited to individuals that create their own package
repositories.
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.
Not quite, the way I view it is that repositories are where the packages
live, although most users won't have to know this. Streams are defined
by the publisher metadata and appropriate tagged packages.
My real question here is whether "stream" and "repository" are really
two concepts or not.
They are.
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.
Right, because streams are just defined by publisher metadata and then
provided by specific, tagged packages (imagine two 'entire' packages,
one tagged with 'dev' and the other with 'release').
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?
At this point, that's the plan. Although, formally, we will likely
allow it to be in a zip, tar.gz, etc. This is part of the tentative
work towards reaching an on-disk format.
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?
Correct.
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.
Yes, this is the basic idea.
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?
No, I suspect we'll still have separate repositories for software
delivered by different groups, but each of those repositories may have
multiple streams. For example, the '/contrib' and '/webstack'
repositories need to stay separate, but could possibly offer their own
streams.
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.
Yes, that is the ultimate goal. In particular, I think it is necessary
for the eventual on-disk format.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
