svn commit: r422505 - head/archivers/snappy-java

Mathieu Arnold mat at FreeBSD.org
Wed Sep 21 13:49:01 UTC 2016


Le 21/09/2016 à 15:43, John Marino a écrit :
> On 9/21/2016 08:39, Mathieu Arnold wrote:
>> Le 21/09/2016 à 15:19, John Marino a écrit :
>>> On 9/21/2016 03:19, Mathieu Arnold wrote:
>>>> Le 20/09/2016 à 17:19, John Marino a écrit :
>>>>> Author: marino
>>>>> Date: Tue Sep 20 15:19:52 2016
>>>>> New Revision: 422505
>>>>> URL: https://svnweb.freebsd.org/changeset/ports/422505
>>>>>
>>>>> Log:
>>>>>   archivers/snappy-java: new fedora MASTER_SITE to unbreak
>>>>
>>>> I'm picking a commit at random.
>>>>
>>>> If our distcache is not a valid upstream, then someone else's
>>>> distcache
>>>> is not either.
>>>
>>> It doesn't look like a cache to me.  It looks like that, unlike
>>> FreeBSD, they keep a copy of distribution tarballs that they use.
>>> It's not a cache, but a primary repository.
>>>
>>> That's what it looks like to me.  If you know that it's definitively
>>> just a cache, that might change the story.
>>
>> From what I can gather, it is the cache fedora uses for building their
>> packages, a bit like what our distcache is. So, well, yes, it is a
>> cache. Like the ubuntu cache you are also using on launchpad.net. or the
>> rpmfusion thing you also found.
>>
>> Trying to go around every rule and policy we have is really getting old.
>>
>
> I'm trying to help.

And it is a noble cause. In the end, what it does is give us more work
because the cache you are using are stuck with one version and will need
way more work to figure out when there is an update.

> It also puts FreeBSD distcache back in the backup role, which is the
> primary discriminator for marking a port broken.

Not it does not, a cache like our distcache, or those other OS caches
cannot be the upstream.

-- 
Mathieu Arnold


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20160921/35aa51a8/attachment.sig>


More information about the svn-ports-all mailing list