fetch.type git & GitHub submodules (was: [133168] trunk/dports/sysutils)

[Rainer Müller]

On 2015-03-04 10:10, Mojca Miklavec wrote:
> On Mon, Mar 2, 2015 at 11:37 AM, Rainer Müller wrote:
>> On 2015-03-02 10:40, Clemens Lang wrote:
>>>
>>> FWIW, the textmate2 Portfile has the same problem, and I've just used
>>>
>>>   fetch.type git
>>>   post-fetch {
>>>       system -W ${worksrcpath} "${git.cmd} submodule update --init"
>>>   }
>>>
>>> to deal with it (which the github PortGroup does not support either, as far as I
>>> can see).
>>
>> The downside of fetch.type git is that it cannot be mirrored and
>> therefore might cause problems behind proxies. Downloads may take
>> longer on larger repos as clone gets the whole history. It also does
>> not support checksums (although git inherently does that).
> 
> But those are all just limitations of MacPorts (the lack of
> functionality in MacPorts) that could be fixed/implemented.
> 
> I see no reason (other than the lack of time or motivation in skilled
> developers and lack of skill in those with time & motivation) why the
> script taking care of mirroring the sources couldn't create a stable
> archive (.tar.xz) from any given tag or commit in a git repository and
> put that file on mirrors. Users could then easily fetch that file only
> (no need to do a git checkout), verify checksums and clean the build
> tree (without having to worry about the need to re-fetch everything).
> 
> Checksums and the need to download history would no longer be an issue then.
> 
> I wouldn't completely dismiss the idea of using git yet.

I agree with you, creating the distfiles from VCS would be possible.

There could be a target to be run on 'port mirror' that downloads and
creates a tarball if a non-default fetch.type is used. That alone would
reduce multiple downloads and even makes port development faster.

However, for end-users, there is the problem that we would need to
distribute checksums for these tarballs (or rely on signatures only?).

Rainer