Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, 5 Jun 2020 21:39:51 -0400 Aaron Bauman wrote: > Of course, the depgraph is not an issue. If a package is > masked, it will break immediately. Hence, required checks > are run then the package is masked. I meant that if $P is removed, then things that $P depends on could also start getting removed, which makes it ever harder and harder to install $P if you need it. I wasn’t talking about things that depend on $P. -- Christopher Head pgppPDza5h85T.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-cdr/sync2d
Ühel kenal päeval, L, 06.06.2020 kell 03:59, kirjutas Ralph Seichter: > * Christopher Head: > > > Not that I care about this specific case, but isn’t the 30-day time > > period also meant as a nice long warning time for people [...] > > Rules and exceptions. I think that shortening the typical 30-day > period > is acceptable in specific cases, and sync2d is one of them. According > to > Git history, the ebuild for release 1.3 (released 2007) was imported > in > August 2015 and no functional changes have been made since then. > There > were only meta data updates and stabilisations, and it all ended in > 2017. > > sync2d is unmaintained in Gentoo and based on Python 2, which, as we > know, was marked for "end of support 2015" which later was extended > to > January 2020. Upstream had oodles of time to migrate to Python 3 if > they > wanted to. If (!) any Gentoo users are still using sync2d today, they > also had ample time to choose an alternative. From all appearances, > sync2d has gone the way of the dodo. > > Masking will not uninstall the package, and the sooner people can no > longer install sync2d without thought, the better, as far as I am > concerned. Portage does not provide a good mechanism of warning users that some package is going or already went away, other than the package.mask entry triggering such a warning. So if it's removed quickly and p.mask removed with that, users of said package will not be notified for a reasonable amount of time to even notice that they have something unmaintained installed. Until that is working better, I find it good to have a package.mask entry for 30 days or even longer. That does not mean the specific package itself can't go away in 15 days - the package.mask entry could be reworded and kept for a bit longer. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: app-cdr/sync2d
* Christopher Head: > Not that I care about this specific case, but isn’t the 30-day time > period also meant as a nice long warning time for people [...] Rules and exceptions. I think that shortening the typical 30-day period is acceptable in specific cases, and sync2d is one of them. According to Git history, the ebuild for release 1.3 (released 2007) was imported in August 2015 and no functional changes have been made since then. There were only meta data updates and stabilisations, and it all ended in 2017. sync2d is unmaintained in Gentoo and based on Python 2, which, as we know, was marked for "end of support 2015" which later was extended to January 2020. Upstream had oodles of time to migrate to Python 3 if they wanted to. If (!) any Gentoo users are still using sync2d today, they also had ample time to choose an alternative. From all appearances, sync2d has gone the way of the dodo. Masking will not uninstall the package, and the sooner people can no longer install sync2d without thought, the better, as far as I am concerned. -Ralph
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, Jun 05, 2020 at 06:27:51PM -0700, Christopher Head wrote: > On Fri, 5 Jun 2020 12:40:17 -0700 > Matt Turner wrote: > > > With that in mind, I don't expect it to gain Python 3 support, nor do > > I expect an additional 15 days of waiting time to change that fact. 15 > > vs 30 days doesn't seem worth squabbling over. > > Not that I care about this specific case, but isn’t the 30-day time > period also meant as a nice long warning time for people *using* the > package to give them time to migrate to something else before it starts > to be unsupported, potentially break the depgraph, no longer be > installable on additional systems, and so on? > -- > Christopher Head That perspective opens a new potential bikeshed. I doubt anyone wants to have anotehr Py2 removal debate... Of course, the depgraph is not an issue. If a package is masked, it will break immediately. Hence, required checks are run then the package is masked. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, 5 Jun 2020 18:27:51 -0700 Christopher Head wrote: > On Fri, 5 Jun 2020 12:40:17 -0700 > Matt Turner wrote: > > > With that in mind, I don't expect it to gain Python 3 support, nor > > do I expect an additional 15 days of waiting time to change that > > fact. 15 vs 30 days doesn't seem worth squabbling over. > > Not that I care about this specific case, but isn’t the 30-day time > period also meant as a nice long warning time for people *using* the > package to give them time to migrate to something else before it > starts to be unsupported, potentially break the depgraph, no longer be > installable on additional systems, and so on? The fact that the tree is git based now. It is easy to checkout the tree and checkout the tree at a state where the pkg is still there. You can then copy it to an overlay to keep around for hownever long. The 30 days were more for when the tree was in CVS. There it was much more complicated to get the pkg from the attic. Also, if it is installed, there is a copy of the ebuild in the installed db: /var/db/pkg/cat/pkg-version The only other potential caveat is that the source tarball must still be available from upstream. Our mirrors will eventually drop the source since the pkg/version is no longer in the ebuild tree.
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, 5 Jun 2020 12:40:17 -0700 Matt Turner wrote: > With that in mind, I don't expect it to gain Python 3 support, nor do > I expect an additional 15 days of waiting time to change that fact. 15 > vs 30 days doesn't seem worth squabbling over. Not that I care about this specific case, but isn’t the 30-day time period also meant as a nice long warning time for people *using* the package to give them time to migrate to something else before it starts to be unsupported, potentially break the depgraph, no longer be installable on additional systems, and so on? -- Christopher Head pgpO1_Yh5m_dG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, Jun 05, 2020 at 12:40:17PM -0700, Matt Turner wrote: > On Fri, Jun 5, 2020 at 9:55 AM Jonas Stein wrote: > > > > On 04/06/2020 01.39, Aaron Bauman wrote: > > > # Aaron Bauman (2020-06-03) > > > # py2 only. dead upstream. m-n. > > > # Masked for removal in 15 days > > > app-cdr/sync2cd > > > > > > > is there a good reason to reduce the time to 15 days? > > > > https://devmanual.gentoo.org/ebuild-maintenance/removal/index.html > > "Wait 30 days (or more)" > > I think we all agree that Python 2-only packages are going to have to > be removed. > > This package is Python 2-only, and it was last released more than 13 > years ago, and the website even says that the project is dead > (http://c-space.org/). > > With that in mind, I don't expect it to gain Python 3 support, nor do > I expect an additional 15 days of waiting time to change that fact. 15 > vs 30 days doesn't seem worth squabbling over. > What Matt said. Just speeds up removal because it is highly unlikely to gain Py3 support. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, Jun 5, 2020 at 9:55 AM Jonas Stein wrote: > > On 04/06/2020 01.39, Aaron Bauman wrote: > > # Aaron Bauman (2020-06-03) > > # py2 only. dead upstream. m-n. > > # Masked for removal in 15 days > > app-cdr/sync2cd > > > > is there a good reason to reduce the time to 15 days? > > https://devmanual.gentoo.org/ebuild-maintenance/removal/index.html > "Wait 30 days (or more)" I think we all agree that Python 2-only packages are going to have to be removed. This package is Python 2-only, and it was last released more than 13 years ago, and the website even says that the project is dead (http://c-space.org/). With that in mind, I don't expect it to gain Python 3 support, nor do I expect an additional 15 days of waiting time to change that fact. 15 vs 30 days doesn't seem worth squabbling over.
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On 04/06/2020 01.39, Aaron Bauman wrote: > # Aaron Bauman (2020-06-03) > # py2 only. dead upstream. m-n. > # Masked for removal in 15 days > app-cdr/sync2cd > is there a good reason to reduce the time to 15 days? https://devmanual.gentoo.org/ebuild-maintenance/removal/index.html "Wait 30 days (or more)" -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-cdr/sync2d
# Aaron Bauman (2020-06-03) # py2 only. dead upstream. m-n. # Masked for removal in 15 days app-cdr/sync2cd -- Cheers, Aaron signature.asc Description: PGP signature
