Re: Python package situation
Hi, On Wed, 17 Feb 2021, Brian May wrote: > I believe there are a number of Python packages in Debian unstable that > are out of date in respect to latest upstream. > > e.g. > https://qa.debian.org/developer.php?login=bam%40debian.org=yes > > Somebody needs to do the work to update them. But maybe the fact that > nobody is doing so, might mean that nobody is using them? Quite often, we introduce Python packages for the need of a specific application and then we don't really see a benefit to upgrade the package unless the application also needs a newer version of the module. That likely explains partly why so many modules are lagging behind. > I personally found a while back that keeping these packages up-to-date > was draining far too much of my time. Time I don't actually have. So I > now use Docker+pip for my applications. On the Kali side, I'm trying to work with Jelmer and his janitor bot to try to automate as much as possible the work of preparing new upstream releases. We're getting close to having something useful where the bot does at least the upstream tarball import and a test rebuild and so on. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Python package situation
On Wed, Feb 17, 2021 at 11:51:52AM +1100, Brian May wrote: > I believe there are a number of Python packages in Debian unstable that > are out of date in respect to latest upstream. > > e.g. > > https://qa.debian.org/developer.php?login=bam%40debian.org=yes > > Somebody needs to do the work to update them. But maybe the fact that > nobody is doing so, might mean that nobody is using them? And/or nobody who uses them is able to update them in Debian or at least report a bug, and/or it's easier to install them directly than update them in Debian and install from there. Also note that many Python module packages in Debian have very low popcon. -- WBR, wRAR signature.asc Description: PGP signature
Re: Python package situation
Andrey Rahmatullin writes: > On Tue, Feb 16, 2021 at 09:48:05PM +0100, Martin wrote: > Are you asking about testing or stable? Because for stable the "packages > are either outdated or do not exist" situation is somewhat expected and > testing is not that interesting case, though even in testing we may have a > lot of outdated packages. I believe there are a number of Python packages in Debian unstable that are out of date in respect to latest upstream. e.g. https://qa.debian.org/developer.php?login=bam%40debian.org=yes Somebody needs to do the work to update them. But maybe the fact that nobody is doing so, might mean that nobody is using them? The packages which are up-to-date have not been updated by upstream in a long time, and this isn't necessarily a good thing either. I personally found a while back that keeping these packages up-to-date was draining far too much of my time. Time I don't actually have. So I now use Docker+pip for my applications. Plus upgrading system packages to fix dependencies always made me worried I might break something unrelated that I couldn't or wasn't ready to fix. So most of the time I don't use these packages anymore. Yes, the idea of the packages being stable in Debian stable, and hence, won't break anything until you do a release upgrade is a good one. But if you encounter a bug/missing feature in such a package that breaks your application, often the only real alternative is to use the latest version. Often only the latest version is supported by upstream also. -- Brian May
Re: Python package situation
On 2021-02-17 02:13, Andrey Rahmatullin wrote: > Are you asking about testing or stable? Because for stable the "packages > are either outdated or do not exist" situation is somewhat expected and > testing is not that interesting case, though even in testing we may have a > lot of outdated packages. At work, we are using stable with backports. Once in a while we make a local package or local backport, too, and put it in our local (reprepro driven) repo. Very often, we can just accept the version in Debian, even if it is not the latest one. > Surely you use only a subset of modules while other people may need a > different subset, and ability to make and upload new or updated packages, > unavailable for most Debian Python users, is definitely helpful. Yes, having upload rights to Debian, incl. backports, is very helpful and I was not implying that it were the same situation for those without that priviledge :-) But at least people on this ML either have that possibility or know how to file RFPs/ITPs or just ask the right people. But that option is less attractive, if the work is far too much, i.e. either too many packages involved or very tricky packages - for technical or other reasons. That's why I'm curious: Maybe the missing packages are the same for multiple people and we can solve the problem?
Re: Python package situation
On Tue, Feb 16, 2021 at 09:48:05PM +0100, Martin wrote: > > I *wish* I could > > just install everything via the Debian Packaging System, but the reality for > > most relevant Python packages is very different: packages are either > > outdated or do not exist in Debian > > Are you talking about many packages? Or only some, that are > difficult to package? Can you give an example? Are you asking about testing or stable? Because for stable the "packages are either outdated or do not exist" situation is somewhat expected and testing is not that interesting case, though even in testing we may have a lot of outdated packages. > At my job, we were always able to stay with Debian packages, or > I just packaged the missing pieces, but maybe our use case is > not that advanced. Surely you use only a subset of modules while other people may need a different subset, and ability to make and upload new or updated packages, unavailable for most Debian Python users, is definitely helpful. -- WBR, wRAR signature.asc Description: PGP signature
