Re: Python 3.x vs 2.7


punit1.agrawal@...
 

Hi Kent,

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

Thank you for your feedback, Iwamatsu-san.

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
[...]

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye
archive 3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

In my opinion, it is difficult to support Python2 for a super long term. And I think
it is difficult to support each library using Python2.
Therefore, I think Option2 is good. And if necessary, we can use
backposts.debian.org.
Actually, option-2 is dominant in the security team as well.
From a brief look at the pros / cons between the two choices (below), I
am also biased towards backporting a python3 based version of duplicity.

Suggested next steps further down -

* Python2

Pros
----
* No backport (to Buster) needed (least effort, right now)

Cons
----
* Has reached EOL in upstream. Not sure about ELTS support. It maybe
that if we go with Python2, we (CIP) is on our own.


* Python3

Pros
----
* Python3 is available in Debian Buster
* Likely to be supported for longer time - upstream and in Debian

Cons
----
* Needs backporting duplicity (and dependencies) to Buster via
backports to align with upstream first approach of CIP.
- From a quick check of dependencies in bullseye a backport of
librsync2 might also be needed.


Next steps
----------
* Investigate the effort to backport duplicity (and dependencies) to
buster-backports.
* If no major surprises are found during the investigation, work with
Debian upstream to upload the new version.

Hope that makes sense.

Thanks,
Punit


However, packages with large dependencies can be difficult to backports. For
example Kbuckup is difficult, I think.
Agree. We are not going to select the package which is GPL-3 or has a lot of dependent package, so the duplicity is only one candidate for us substantially.

Best regards,
Nobuhiro

From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento
Yoshida
Sent: Thursday, April 2, 2020 6:59 PM
To: cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: [cip-dev] Python 3.x vs 2.7

Hi CIP core group,

The security package proposal is suspended now, but I'd like to discuss about the
python version which is suitable to maintain.

We selected "duplicity" for the requirement of system backup according to the
functionality, license, the number of dependencies and so on.
However, the duplicity in the Debian buster [1] dependent on python 2.7, which is
not maintained anymore [2].

[1] https://packages.debian.org/source/buster/duplicity
[2] https://pythonclock.org/

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive 3.
Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

FYI, unfortunately we couldn't find the alternative package for system backup. The
duplicity is the best package for us from the license and num of dependencies
point of view.
See the following.

<Rsync>
Encryption: No
Schedule backup: No
Incremental backup: Yes
License: GPL v3
Dependencies count (aprox): 24
Reference: https://rsync.samba.org/features.html

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

<Backuppc>
Encryption: No
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+, X11
Dependencies count (aprox): 132
Reference: http://backuppc.sourceforge.net/info.html

<Amanda>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+
Dependencies count (aprox): 289
Reference: https://www.zmanda.com/amanda-community-edition.html

<Kbackup>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV Dependencies count (aprox): 414
Reference: https://kde.org/applications/utilities/org.kde.kbackup

Best regards,
Kent
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Join cip-dev@lists.cip-project.org to automatically receive all group messages.