Re: Removing python2 packages
Samuel Thibault, le mer. 31 juil. 2019 03:08:22 +0200, a ecrit: > IIRC, the uncruft script doesn't react immediately, you'd have to wait > for something like days or a couple of weeks. That said, https://ftp-master.debian.org/cruft-report-daily.txt doesn't show these python packages, e.g. python-louis which has been dropped from testing, but not from unstable yet. Samuel
Re: Removing python2 packages
Samuel Thibault, le mer. 31 juil. 2019 03:08:22 +0200, a ecrit: > Thomas Goirand, le mer. 31 juil. 2019 00:13:24 +0200, a ecrit: > > On 7/30/19 11:40 PM, Scott Talbert wrote: > > > On Tue, 30 Jul 2019, Thomas Goirand wrote: > > >> Do you mean, will python-foo be automatically removed from Sid/Testing, > > >> after your upload? Normally yes, if nothing depends on it. And that's > > >> probably harder to find out than one may think... :) > > > > > > Yes, that's what I mean. The reason I ask is because I've done such an > > > upload (with python-xyz removed), but this package hasn't disappeared > > > from the python2-rm transition tracker. The specific package involved > > > is concordance (python-libconcord was removed). > > > > cc-ing the FTP master team. > > > > My understanding is that there's issues with arch:all package in the > > uncruft script of the FTP masters. It looks like a lot of python-* > > packages are staying. > > IIRC, the uncruft script doesn't react immediately, you'd have to wait > for something like days or a couple of weeks. (and possibly the removal is triggered by hand, the uncruft script only pointing out what apparently needs to be removed) Samuel
Re: Removing python2 packages
Thomas Goirand, le mer. 31 juil. 2019 00:13:24 +0200, a ecrit: > On 7/30/19 11:40 PM, Scott Talbert wrote: > > On Tue, 30 Jul 2019, Thomas Goirand wrote: > >> Do you mean, will python-foo be automatically removed from Sid/Testing, > >> after your upload? Normally yes, if nothing depends on it. And that's > >> probably harder to find out than one may think... :) > > > > Yes, that's what I mean. The reason I ask is because I've done such an > > upload (with python-xyz removed), but this package hasn't disappeared > > from the python2-rm transition tracker. The specific package involved > > is concordance (python-libconcord was removed). > > cc-ing the FTP master team. > > My understanding is that there's issues with arch:all package in the > uncruft script of the FTP masters. It looks like a lot of python-* > packages are staying. IIRC, the uncruft script doesn't react immediately, you'd have to wait for something like days or a couple of weeks. Samuel
Re: Removing python2 packages
On 7/30/19 11:40 PM, Scott Talbert wrote: > On Tue, 30 Jul 2019, Thomas Goirand wrote: >> Do you mean, will python-foo be automatically removed from Sid/Testing, >> after your upload? Normally yes, if nothing depends on it. And that's >> probably harder to find out than one may think... :) > > Yes, that's what I mean. The reason I ask is because I've done such an > upload (with python-xyz removed), but this package hasn't disappeared > from the python2-rm transition tracker. The specific package involved > is concordance (python-libconcord was removed). > > Scott cc-ing the FTP master team. My understanding is that there's issues with arch:all package in the uncruft script of the FTP masters. It looks like a lot of python-* packages are staying. I told about it to Luke at Debconf, though I'm not sure if he had time to look into it. Dear FTP master team, As per above, this is an increasingly annoying issue that prevents us from knowing what thing we should work on. Is the uncruft script really broken? If yes, were should we look into, if we want to contribute a fix? A pointer to the correct script in a git Salsa (if there's such a thing), and advice on how to test would be helpful. Is this directly in the Dak's sources? Thomas Goirand (zigo)
Re: Removing python2 packages
On Tue, 30 Jul 2019, Thomas Goirand wrote: Hi, út 23. 7. 2019 v 11:40 odesílatel Scott Talbert napsal: When removing leaf python2 packages for bullseye, is there anything __modules__ package :) special that needs to be done, other than removing the building of the python2 subpackage? For example, obsoleting of the old package or anything along those lines? * check reverse-depends and "reverse-depends -b" * remove from d/control * remove from d/tests * remove from d/rules * check/remove d/python-* files * test * upload After doing the above, does anything have to be done to remove the python2 binary package from the archive? No. You must *not* add breaks or conflicts. Is it removed automatically by some sort of garbage collection or do I have to file a bug to have it removed? Do you mean, will python-foo be automatically removed from Sid/Testing, after your upload? Normally yes, if nothing depends on it. And that's probably harder to find out than one may think... :) Yes, that's what I mean. The reason I ask is because I've done such an upload (with python-xyz removed), but this package hasn't disappeared from the python2-rm transition tracker. The specific package involved is concordance (python-libconcord was removed). Scott
Re: Removing python2 packages
On 7/30/19 3:45 PM, Scott Talbert wrote: > On Tue, 23 Jul 2019, Ondrej Novy wrote: > >> Hi, >> >> út 23. 7. 2019 v 11:40 odesílatel Scott Talbert napsal: >> When removing leaf python2 packages for bullseye, is there >> anything >> >> >> __modules__ package :) >> >> special that needs to be done, other than removing the building >> of the >> python2 subpackage? >> >> For example, obsoleting of the old package or anything along >> those lines? >> >> >> * check reverse-depends and "reverse-depends -b" >> * remove from d/control >> * remove from d/tests >> * remove from d/rules >> * check/remove d/python-* files >> * test >> * upload > > After doing the above, does anything have to be done to remove the > python2 binary package from the archive? No. You must *not* add breaks or conflicts. > Is it removed automatically by > some sort of garbage collection or do I have to file a bug to have it > removed? Do you mean, will python-foo be automatically removed from Sid/Testing, after your upload? Normally yes, if nothing depends on it. And that's probably harder to find out than one may think... :) Thomas Goirand (zigo)
Re: Removing python2 packages
On 7/24/19 8:44 PM, Scott Talbert wrote: > Assuming python 2 is removed from bullseye, upon an upgrade from buster > to bullseye, I guess we are assuming python 2 would remain installed on > upgraded systems? > > Scott We discussed this during Debconf. Possibly, we'll have to leave the Python 2 interpreter in Bullseye to be able to upgrade, and also maybe to build pypy3. As written previously, after the upgrade this would be strongly advised: apt-get --purge autoremove When the time comes, we probably will need to write about it in the Bullseye release notes. Though that's far from now... Cheers, Thomas Goirand (zigo)
Re: Removing python2 packages
On Tue, 23 Jul 2019, Ondrej Novy wrote: Hi, út 23. 7. 2019 v 11:40 odesílatel Scott Talbert napsal: When removing leaf python2 packages for bullseye, is there anything __modules__ package :) special that needs to be done, other than removing the building of the python2 subpackage? For example, obsoleting of the old package or anything along those lines? * check reverse-depends and "reverse-depends -b" * remove from d/control * remove from d/tests * remove from d/rules * check/remove d/python-* files * test * upload After doing the above, does anything have to be done to remove the python2 binary package from the archive? Is it removed automatically by some sort of garbage collection or do I have to file a bug to have it removed? Scott
Re: Removing python2 packages
On Wed, 24 Jul 2019, Neil Williams wrote: út 23. 7. 2019 v 11:40 odesílatel Scott Talbert napsal: When removing leaf python2 packages for bullseye, is there anything __modules__ package :) special that needs to be done, other than removing the building of the python2 subpackage? For example, obsoleting of the old package or anything along those lines? * check reverse-depends and "reverse-depends -b" * remove from d/control * remove from d/tests * remove from d/rules * check/remove d/python-* files * test * upload Thanks. The reason I asked about 'obsoleting' is because I wondered about what will happen on the upgrade case. Say, I remove python-foo from bullseye. When a user running buster with python-foo installed upgrades to bullseye, what will happen? Will apt try to remove python-foo? Not unless something actually Breaks: or Conflicts: or the user runs autoremove. If a leaf package bar changes from Depends: python-foo to python3-foo, then python-foo will remain installed. There are lots of packages in Stretch that are not in Buster. Upgrading leaves them in place unless there is something which actively Conflicts: or Breaks: them. That's why autoremove is so useful after dist-upgrade. What about reverse dependencies that are "Suggests" vice "Depends?" Do all Suggests dependencies needs to be removed first as well? NOTE: reverse-depends (aside from '-b' being broken in unstable right now), does not seem to show Suggests dependencies by default.
Re: Removing python2 packages
On July 24, 2019 4:08:54 PM UTC, Scott Talbert wrote: >On Tue, 23 Jul 2019, Ondrej Novy wrote: > >> út 23. 7. 2019 v 11:40 odesílatel Scott Talbert >napsal: >> When removing leaf python2 packages for bullseye, is there >> anything >> >> >> __modules__ package :) >> >> special that needs to be done, other than removing the building >> of the >> python2 subpackage? >> >> For example, obsoleting of the old package or anything along >> those lines? >> >> >> * check reverse-depends and "reverse-depends -b" >> * remove from d/control >> * remove from d/tests >> * remove from d/rules >> * check/remove d/python-* files >> * test >> * upload > >Thanks. The reason I asked about 'obsoleting' is because I wondered >about >what will happen on the upgrade case. Say, I remove python-foo from >bullseye. When a user running buster with python-foo installed >upgrades >to bullseye, what will happen? Will apt try to remove python-foo? It depends (pun intended). I've recently upgraded some Python applications to python3, so python-foo depends changed to python3-foo. If the only reason python-foo was installed was because it was a dependency of the application, then it'll be eligible for apt autoremove. Scott K
Re: Removing python2 packages
On Wed, 24 Jul 2019, Neil Williams wrote: napsal: When removing leaf python2 packages for bullseye, is there anything __modules__ package :) special that needs to be done, other than removing the building of the python2 subpackage? For example, obsoleting of the old package or anything along those lines? * check reverse-depends and "reverse-depends -b" * remove from d/control * remove from d/tests * remove from d/rules * check/remove d/python-* files * test * upload Thanks. The reason I asked about 'obsoleting' is because I wondered about what will happen on the upgrade case. Say, I remove python-foo from bullseye. When a user running buster with python-foo installed upgrades to bullseye, what will happen? Will apt try to remove python-foo? Not unless something actually Breaks: or Conflicts: or the user runs autoremove. If a leaf package bar changes from Depends: python-foo to python3-foo, then python-foo will remain installed. There are lots of packages in Stretch that are not in Buster. Upgrading leaves them in place unless there is something which actively Conflicts: or Breaks: them. That's why autoremove is so useful after dist-upgrade. Assuming python 2 is removed from bullseye, upon an upgrade from buster to bullseye, I guess we are assuming python 2 would remain installed on upgraded systems? Scott
Re: Removing python2 packages
On Wed, 24 Jul 2019 12:08:54 -0400 (EDT) Scott Talbert wrote: > On Tue, 23 Jul 2019, Ondrej Novy wrote: > > > út 23. 7. 2019 v 11:40 odesílatel Scott Talbert > > napsal: When removing leaf python2 packages for bullseye, is there > > anything > > > > > > __modules__ package :) > > > > special that needs to be done, other than removing the > > building of the > > python2 subpackage? > > > > For example, obsoleting of the old package or anything along > > those lines? > > > > > > * check reverse-depends and "reverse-depends -b" > > * remove from d/control > > * remove from d/tests > > * remove from d/rules > > * check/remove d/python-* files > > * test > > * upload > > Thanks. The reason I asked about 'obsoleting' is because I wondered > about what will happen on the upgrade case. Say, I remove python-foo > from bullseye. When a user running buster with python-foo installed > upgrades to bullseye, what will happen? Will apt try to remove > python-foo? Not unless something actually Breaks: or Conflicts: or the user runs autoremove. If a leaf package bar changes from Depends: python-foo to python3-foo, then python-foo will remain installed. There are lots of packages in Stretch that are not in Buster. Upgrading leaves them in place unless there is something which actively Conflicts: or Breaks: them. That's why autoremove is so useful after dist-upgrade. > > Scott -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpjaUC4ltKPU.pgp Description: OpenPGP digital signature
Re: Removing python2 packages
On Tue, 23 Jul 2019, Ondrej Novy wrote: út 23. 7. 2019 v 11:40 odesílatel Scott Talbert napsal: When removing leaf python2 packages for bullseye, is there anything __modules__ package :) special that needs to be done, other than removing the building of the python2 subpackage? For example, obsoleting of the old package or anything along those lines? * check reverse-depends and "reverse-depends -b" * remove from d/control * remove from d/tests * remove from d/rules * check/remove d/python-* files * test * upload Thanks. The reason I asked about 'obsoleting' is because I wondered about what will happen on the upgrade case. Say, I remove python-foo from bullseye. When a user running buster with python-foo installed upgrades to bullseye, what will happen? Will apt try to remove python-foo? Scott
Re: Removing python2 packages
On 2019/07/23 11:40, Scott Talbert wrote: > When removing leaf python2 packages for bullseye, is there anything > special that needs to be done, other than removing the building of the > python2 subpackage? > > For example, obsoleting of the old package or anything along those lines? Another thing that happened to me that was mentioned in the BoF yesterday... if you decide to merge back the -doc package you have to remember to file an rm for that binary doc package otherwise it will just remain as cruft. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Removing python2 packages
On Tue, 23 Jul 2019 10:40:29 -0400 (EDT) Scott Talbert wrote: > When removing leaf python2 packages for bullseye, is there anything > special that needs to be done, other than removing the building of > the python2 subpackage? > > For example, obsoleting of the old package or anything along those > lines? Obsoleting would infer that the Python2 version hangs around in some way. That would defeat the object somewhat. Most leaf packages will be binaries, so the binary can just change to Python3. If there's a Python2 module or other support package, just drop it. Put an entry in NEWS if you think people may have out-of-distro scripts using the Python2 module. Otherwise, a note in README.Debian or just debian/changelog is probably enough. It's fairly obvious when a Python leaf binary moves to Python3 support. As long it continues to work, most users aren't going to even notice. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpzUYLNoBm9B.pgp Description: OpenPGP digital signature
Re: Removing python2 packages
Hi, út 23. 7. 2019 v 11:40 odesílatel Scott Talbert napsal: > When removing leaf python2 packages for bullseye, is there anything > __modules__ package :) > special that needs to be done, other than removing the building of the > python2 subpackage? > > For example, obsoleting of the old package or anything along those lines? > * check reverse-depends and "reverse-depends -b" * remove from d/control * remove from d/tests * remove from d/rules * check/remove d/python-* files * test * upload -- Best regards Ondřej Nový
