Re: Version Woes

[EricZolf]

Hi,

let me perhaps intervene and have everybody calm down a bit.

Frank is only the messenger and doesn't make the rules of Fedora, so
please don't shoot him.

Derek, you might be correct that we will see Python 2 for decades,
nothing lives longer than zombies (see IBM and mainframes), but the fact
that Python 2 will not get anymore security and bug fixes from the
Python project is also a fact (meaning each distribution is on its own,
and might or not do its job), so we should all work towards getting
everybody off it asap _and_ organize a smooth transition for the
rdiff-users.

If we agree on the objectives, let's come back to the actual topic, on
how to make this real. I must honestly say that I lost sight of where we
stand, as the discussion became heated.

If someone could summarize what is already granted as being possible and
what not, that would help.

Thanks, Eric

On 30/04/2020 17:23, Derek Atkins wrote:
> Frank,
> 
> Frank Crawford <address@hidden> writes:
> 
>> I don't know about other distributions, but Fedora is actively
>> discouraging any Python2 applications.
>>
>> Python 2.6 and Python 2.7 is only for essential applications that have
>> not yet been ported, and actually need approval to ship.  If there is
>> already a port of an application to Python3,such as rdiff-backup,
>> approval will not gain approval.
> 
> So backup isn't essential?
> 
>> In fact, if you review what is available in Fedora 32 you will see that
>> most things that had both Python2 and Python3 versions now only have
>> Python3 versions, and many other things have just been dropped.
> 
> Sure, but rdiff-backup is special because version 2 is not backwards
> compatible with version 1 over-the-net.  If it were, we wouldn't be
> having this conversation.  However if you have a client/server backup
> solution using rdiff-backup, right now both ends need to be the same
> version.  This means there needs to be a transition period where both
> versions are available.
> 
> I think this argument can easily be made.
> 
>>> So, frankly, based on that 2.6 is still being shipped after 7 years,
>>> I
>>> think we have a good DECADE before we'll stop seeing Python 2.7.
>>
>> The biggest issue with running any Python2 packages is that there will
>> be no security patches for the underlying framework.
> 
> I don't see that being an issue..
> 
>> Saying that, there is nothing stopping you from pulling down an old
>> copy of rdiff-backup 2.8 and maintaining it yourself, as once you put
>> it on there, nothing will change (ever).
>>
>> In addition you can run both rdiff-backup 1.2.8 and 2.0.0 on the same
>> system, however, you will have to do the renaming required to hold
>> both.  With package installation, we have to ensure that the names and
>> metadata are different, otherwise you get clashes which stop the
>> installation of one or other of the packages.
> 
> I don't see why we can't have an "rdiff-backup" which is version 2, and
> an "rdiff-backup1" which is 1.2.8.  It's not the first time this has
> been done before.
> 
> Just look at Mailman!  Fedora ships both Mailman2 and Mailman3 packages
> which can co-exist on a server.
> 
> Sure, *I* could go install both myself and solve the problem for myself.
> That's not the point.  The point is to make sure someone who is just a
> regular software user doesn't get boned because they update one system
> and suddenly their backup solution doesn't work anymore.
> 
>>> -derek
>>
>> Regards
>> Frank
> 
> -derek
>