On Thu, Oct 26, 2017 at 10:12:25PM +0200, Michał Górny wrote:
> Hi, everyone.
>
> After a week of hard work, I'd like to request your comments
> on the draft of GLEP 74. This GLEP aims to replace the old tree-signing
> GLEPs 58 and 60 with a superior implementation and more complete
> specificatio
Hi,
On Thu, 26 Oct 2017 22:12:25 +0200
Michał Górny wrote:
> After a week of hard work, I'd like to request your comments
> on the draft of GLEP 74. This GLEP aims to replace the old
> tree-signing GLEPs 58 and 60 with a superior implementation and more
> complete specification.
Thanks for work
On 10/27/17 17:48, Hanno Böck wrote:
> Should a package manager reject a sync if it is too old? or not install
> packages if a sync hasn't happened for some time? What is considered
> "outdated"? I think that should be clarified how exactly it's supposed
> to work.
>
If such a rejection is to be t
On 10/27/17 02:22, Michał Górny wrote:
> Yes. We can't technically distinguish intentional package removal by user
> from malicious third party stripping them. This is something that a package
> manager extension might handle but it doesn't belong in the spec.
>
"Implementations may provide mech
On 28/10/17 03:41, Dean Stephens wrote:
> On 10/27/17 17:48, Hanno Böck wrote:
>> Should a package manager reject a sync if it is too old? or not install
>> packages if a sync hasn't happened for some time? What is considered
>> "outdated"? I think that should be clarified how exactly it's supposed
On 28.10.2017 05:27, M. J. Everitt wrote:
> On 28/10/17 03:41, Dean Stephens wrote:
>> On 10/27/17 17:48, Hanno Böck wrote:
>>> Should a package manager reject a sync if it is too old? or not install
>>> packages if a sync hasn't happened for some time? What is considered
>>> "outdated"? I think th
On Tue, Oct 24, 2017 at 9:40 PM, Robin H. Johnson wrote:
> On Tue, Oct 24, 2017 at 11:33:39PM +0200, Allan Wegan wrote:
>> >> That is currently the case with portage, but not an inevitable
>> >> consequence of having 3 hash functions in the Manifest. Portage could
>> >> be made to check only one o
