Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #11517 > unrolled thread

Removing python2 packages

Back to article view | Back to linux.debian.maint.python

Contents

  Removing python2 packages Scott Talbert <swt@techie.net> - 2019-07-23 16:50 +0200
    Re: Removing python2 packages Neil Williams <codehelp@debian.org> - 2019-07-23 19:50 +0200
    Re: Removing python2 packages Ondrej Novy <novy@ondrej.org> - 2019-07-23 19:50 +0200
      Re: Removing python2 packages Scott Talbert <swt@techie.net> - 2019-07-24 18:10 +0200
        Re: Removing python2 packages Neil Williams <codehelp@debian.org> - 2019-07-24 20:10 +0200
          Re: Removing python2 packages Scott Talbert <swt@techie.net> - 2019-07-24 20:50 +0200
          Re: Removing python2 packages Scott Talbert <swt@techie.net> - 2019-07-26 15:50 +0200
        Re: Removing python2 packages Scott Kitterman <debian@kitterman.com> - 2019-07-24 23:40 +0200
      Re: Removing python2 packages Scott Talbert <swt@techie.net> - 2019-07-30 15:50 +0200
        Re: Removing python2 packages Scott Talbert <swt@techie.net> - 2019-07-30 23:50 +0200
          Re: Removing python2 packages Samuel Thibault <sthibault@debian.org> - 2019-07-31 03:10 +0200
          Re: Removing python2 packages Samuel Thibault <sthibault@debian.org> - 2019-07-31 03:10 +0200
            Re: Removing python2 packages Samuel Thibault <sthibault@debian.org> - 2019-07-31 03:30 +0200
    Re: Removing python2 packages Jonathan Carter <jcc@debian.org> - 2019-07-23 21:30 +0200

#11517 — Removing python2 packages

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?

Scott

[toc] | [next] | [standalone]

#11518

[Multipart message — attachments visible in raw view] — view raw

On Tue, 23 Jul 2019 10:40:29 -0400 (EDT)
Scott Talbert <swt@techie.net> 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/

[toc] | [prev] | [next] | [standalone]

#11520

[Multipart message — attachments visible in raw view] — view raw

Hi,

út 23. 7. 2019 v 11:40 odesílatel Scott Talbert <swt@techie.net> 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ý

[toc] | [prev] | [next] | [standalone]

#11527

[Multipart message — attachments visible in raw view] — view raw

On Tue, 23 Jul 2019, Ondrej Novy wrote:

> út 23. 7. 2019 v 11:40 odesílatel Scott Talbert <swt@techie.net> 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

[toc] | [prev] | [next] | [standalone]

#11528

[Multipart message — attachments visible in raw view] — view raw

On Wed, 24 Jul 2019 12:08:54 -0400 (EDT)
Scott Talbert <swt@techie.net> wrote:

> On Tue, 23 Jul 2019, Ondrej Novy wrote:
> 
> > út 23. 7. 2019 v 11:40 odesílatel Scott Talbert <swt@techie.net>
> > 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/

[toc] | [prev] | [next] | [standalone]

#11529

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#11531

[Multipart message — attachments visible in raw view] — view raw

On Wed, 24 Jul 2019, Neil Williams wrote:

>>> út 23. 7. 2019 v 11:40 odesílatel Scott Talbert <swt@techie.net>
>>> 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.

[toc] | [prev] | [next] | [standalone]

#11530

On July 24, 2019 4:08:54 PM UTC, Scott Talbert <swt@techie.net> wrote:
>On Tue, 23 Jul 2019, Ondrej Novy wrote:
>
>> út 23. 7. 2019 v 11:40 odesílatel Scott Talbert <swt@techie.net>
>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

[toc] | [prev] | [next] | [standalone]

#11538

[Multipart message — attachments visible in raw view] — view raw

On Tue, 23 Jul 2019, Ondrej Novy wrote:

> Hi,
> 
> út 23. 7. 2019 v 11:40 odesílatel Scott Talbert <swt@techie.net> 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

[toc] | [prev] | [next] | [standalone]

#11539

[Multipart message — attachments visible in raw view] — view raw

On Tue, 30 Jul 2019, Thomas Goirand wrote:

>>> Hi,
>>>
>>> út 23. 7. 2019 v 11:40 odesílatel Scott Talbert <swt@techie.net> 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

[toc] | [prev] | [next] | [standalone]

#11540

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

[toc] | [prev] | [next] | [standalone]

#11541

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

[toc] | [prev] | [next] | [standalone]

#11542

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

[toc] | [prev] | [next] | [standalone]

#11521

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) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web