Indeed, R6RS does. Admittedly I was more so thinking about R7RS when writing that message, sorry for confusion. I agree manager shouldn't be adding layer of version if it already exists,
but what if it doesn't? Would a semi-formal convention to name libraries in R7RS with a version as last name-part be enough? Consider chain A (enduser app) depends on B (some framework), which in turn depends on C (utility library). 
As an A author I want to have possibility of control over the C version, particularly so if need be, I can use a newer C version than what B depends on in the case of api-nonbreaking bug fixes. If B imports its C import with `(import (C v1))`, 
it's not entirely clear to me in what way library manager would trick B to actually use (C v1.0.1) instead.

2021-01-27, tr, 10:37 Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> rašė:

How would versioning come to play? Packages (at least the ones I use -- maven, npm) tend to have versions as first class construct,
that are just important for resolution as and the name. But otoh, versioning isn't part of the library itself it seems.
I mean, we don't generally do `(import (foo bar baz v1.2))`

R6RS libraries are versioned. Any package manager/library repository shouldn't add a second layer of versioning on top of it but understand it.

 


2021-01-27, tr, 03:34 Vladimir Nikishkin <xxxxxx@gmail.com> rašė:
Another problem with packages, that Scheme is not yet facing, but which
it may actually face in the future, is that Linux distributions tend to
package individual libraries into their own package repositories, rather
than relying on language distributions' package repositories.


On 27/01/2021 06:49, Lassi Kortela wrote:
> It would be a good time to start experimenting with the grand unified
> index of Scheme libraries/packages. It'll be a long project, so best get
> going early.
>
> First off, should that be library or package?
>
> lib.scheme.org
> libs.scheme.org
>
> pkg.scheme.org
> pkgs.scheme.org
>
> Most languages have a _package_ manager, where a package is a collection
> of libraries (+ some auxiliary files). I don't know about others, but
> I've always found this two-layer approach confusing.
>
> R6RS and R7RS only talk about libraries, which are a logical and easily
> understood unit that ties neatly into the language semantics. By
> contrast, a collection of libraries is an administrative concern. If I
> want to import library (foo bar baz), do I really need to know which
> collection it comes from? If the library comes from a particular git
> repo or tar file, can't the package manager find that collection for me
> and figure out how to extract the library that I want (as well as any
> other libraries that it depends on).
>
> Package managers need to do dependency-chasing anyway in order to
> resolve packages that depend on other packages. It shouldn't be more
> work to do that on a library level as opposed to a package level.