On 7/14/15, 10:41, "Monty Taylor" wrote:
>On 07/14/2015 11:08 AM, Ian Cordasco wrote:
>>
>>
>> On 7/13/15, 16:19, "Joshua Harlow" wrote:
>>
>>> Ian Cordasco wrote:
On 7/13/15, 15:09, "Dave Walker" wrote:
> On 13 Jul 2015 8:52 pm, "Ian Cordasco"
> wrote:
>> On 7/1
Monty Taylor wrote:
> [...]
> An epoch, being a tool designed for package maintainers to solve package
> maintainer problems, is not a tool designed to solve ease of
> communication issues for regular users. Most regular users immediately
> grasp that 2.0.0 > 1.0.0. Most regular users do NOT intuit
On 07/14/2015 11:08 AM, Ian Cordasco wrote:
>
>
> On 7/13/15, 16:19, "Joshua Harlow" wrote:
>
>> Ian Cordasco wrote:
>>>
>>> On 7/13/15, 15:09, "Dave Walker" wrote:
>>>
On 13 Jul 2015 8:52 pm, "Ian Cordasco"
wrote:
> On 7/13/15, 03:38, "Thierry Carrez" wrote:
>> By "co
On 7/13/15, 16:19, "Joshua Harlow" wrote:
>Ian Cordasco wrote:
>>
>> On 7/13/15, 15:09, "Dave Walker" wrote:
>>
>>> On 13 Jul 2015 8:52 pm, "Ian Cordasco"
>>>wrote:
On 7/13/15, 03:38, "Thierry Carrez" wrote:
>>>
> By "counter-productive", I meant: likely to generate more confusion
>
Ian Cordasco wrote:
On 7/13/15, 15:09, "Dave Walker" wrote:
On 13 Jul 2015 8:52 pm, "Ian Cordasco" wrote:
On 7/13/15, 03:38, "Thierry Carrez" wrote:
By "counter-productive", I meant: likely to generate more confusion
than
clarity. If you provide an epoch in the version and it doesn't
On 13 July 2015 at 21:58, Ian Cordasco wrote:
> On 7/13/15, 15:09, "Dave Walker" wrote:
>
>>
>>Therefore, these distro's would need to increment the distro epoch if the
>>upstream version (without the upstream epoch) is lower than the version
>>currently in their archives.
>>I am not sure how rp
On 7/13/15, 15:09, "Dave Walker" wrote:
>
>On 13 Jul 2015 8:52 pm, "Ian Cordasco" wrote:
>> On 7/13/15, 03:38, "Thierry Carrez" wrote:
>
>> >By "counter-productive", I meant: likely to generate more confusion
>>than
>> >clarity. If you provide an epoch in the version and it doesn't match
>> >
On 13 Jul 2015 8:52 pm, "Ian Cordasco" wrote:
> On 7/13/15, 03:38, "Thierry Carrez" wrote:
> >By "counter-productive", I meant: likely to generate more confusion than
> >clarity. If you provide an epoch in the version and it doesn't match
> >downstream packagers ones, it's hard to rely on it.
>
On 7/13/15, 03:38, "Thierry Carrez" wrote:
>Ian Cordasco wrote:
>> On 7/10/15, 03:44, "Thierry Carrez" wrote:
>>> Also you'll find that the various distros use different epoch values
>>>for
>>> the same software, because epoch are also used to cover local blunders
>>> in packaging and historic
Ian Cordasco wrote:
> On 7/10/15, 03:44, "Thierry Carrez" wrote:
>> Also you'll find that the various distros use different epoch values for
>> the same software, because epoch are also used to cover local blunders
>> in packaging and historical artifacts. That is why epochs should be
>> local to
Ian Cordasco wrote:
On 7/10/15, 03:44, "Thierry Carrez" wrote:
Joshua Harlow wrote:
Hi all,
I was thinking about those who are packaging with venvs (and using the
version of a project in the venv file name); like what anvil[1] is now
capable of (and does this in the gate now[2]) or packagin
On 7/10/15, 03:44, "Thierry Carrez" wrote:
>Joshua Harlow wrote:
>> Hi all,
>>
>> I was thinking about those who are packaging with venvs (and using the
>> version of a project in the venv file name); like what anvil[1] is now
>> capable of (and does this in the gate now[2]) or packaging via r
Joshua Harlow wrote:
> Hi all,
>
> I was thinking about those who are packaging with venvs (and using the
> version of a project in the venv file name); like what anvil[1] is now
> capable of (and does this in the gate now[2]) or packaging via rpms
> (which anvil also does) and they are going to b
Hi all,
I was thinking about those who are packaging with venvs (and using the
version of a project in the venv file name); like what anvil[1] is now
capable of (and does this in the gate now[2]) or packaging via rpms
(which anvil also does) and they are going to be affected by the version
sh
14 matches
Mail list logo
