fetch.type git & GitHub submodules (was: [133168] trunk/dports/sysutils)
Mojca Miklavec
mojca at macports.org
Wed Mar 4 13:27:18 PST 2015
On Wed, Mar 4, 2015 at 12:02 PM, Rainer Müller wrote:
> 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?).
Of course we would have to distribute the checksums in that case, like
for any other port. What exactly is considered a "problem" here?
Mojca
More information about the macports-dev
mailing list