Darren J Moffat wrote:
Shawn Walker wrote:
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.
So are say users only need to know about repositories and not streams ?
That would be nice because that I believe would line up the terminology
with what other systems use (ie repository rather than stream).
So, other distributions use repository separation to define streams from
what I recall. For example, Ubuntu puts each release in its own
separate package repository.
But that doesn't really work so well with our 'dev' and 'release' trains.
For example, if streams and repositories are synonymous, then for a user
to switch between the 'release' and 'dev' they could only have one of
those repositories enabled. But ideally, we want users (barring package
constraints) to be able to mix and match packages from those two
separate repositories. A great example of this would be unbundled
packages that currently exist in the 'dev' and 'release' repositories
that aren't really part of the 'dev' and 'release' software train.
Another problem with relying on repository for software train identity
(long-term) is what happens to that identity when a user gets an on-disk
copy of it. In other words, if the user uses pkgrecv to get a copy of
the sunstudio package from the /dev repository, and then a driver from
the /support repository, to sneaker-net that over to another system, how
do I know which software train those packages are for unless they've
been tagged? Hence, streams.
Cheers,
-
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
