Olivier Andrieu wrote:
>> I think that it's somewhat strange to incorporate the source for all
>> packages into one massive VCS, and it looks like that's what's been
>> proposed.
>>
>> Metadata references tarballs.
>>     
>
> Having metadata point to the upstream VCS isn't necessarily difficult,
> lots of build systems support that.
> It can be as simple as using the right URI: http:// ftp:// for
> tarballs, svn://, hg:// git://, etc. for a VCS.
> The user doesn't need to know how to operate the VCS, the build system
> does this for him.
>   


...meaning that the user has to install *all* possible VCSs on *all* 
machines where an application is to be built? Looks like a maintenance 
nightmare to me.

>> I don't see a
>> whole lot of merit for hooking into upstream VCS for the general case,
>> as most users will probably want to use released tarballs of
>> everything except the few modules they're working on.
>>     
>
> Speaking as the author of a caml binding library that has no published
> tarball, I don't see a lot of merit for preventing access to those VCS
> either :)
> A revision id or tag on a repository is as good as a tarball for
> referencing a precise state of some software component.
>   

This is about introducing yet another concept into the package 
management system, which doesn't simplify that at all.

I think the system needs to use the least common denominator as a basic 
transport if we want it to be widely adopted. Which is, I believe, 
HTTP/FTP in today's world.

-- 
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com