Earlier quoted context omitted.
Can you link to a few maintained packages that only support Python 2?
This one is relatively maintained, for example: https://github.com/pyroscope/pyrocore
Last release was all the way back in 2017?
Debian still having trouble with merged /usr
231–240 of 310 posts
Re: Debian still having trouble with merged /usr
#232Earlier quoted context omitted.
As far as I can find there are issues, namely that installing a package with dpkg can leave the system in a bad state. If I understand it correctly dpkg normally prevents by checking the paths it modifies, which ends up non trivial if the paths are aliased. > the dpkg maintainer it's being a jerk. He is required to accept working patches, priority by the committee seems to be the removal of warnings about the broken…
> He is required to accept working patches The thing is that no one wants to interact with a maintainer hostile to the very idea of your patch. Sure, they may be "required" to accept it, but it's not going to be a fun process for anyone involved. Part of Boccassi's concern with their patch is that it might not be merged at all due to what they perceive as "moving goalposts" and "excuses". I think that's not entirely…
> The thing is that no one wants to interact with a maintainer hostile to the very idea
His hostility seems to be based on actual reasons if it is true that other systems that performed the unification basically throw out any guarantees made by dpkg. Providing a patch that fixes that would get rid of those reasons.
> Part of Boccassi's concern with their patch is that it might not be merged at all due to what they perceive as "moving goalposts" and "excuses".
Bocassi is also the guy who claimed the first incomplete patch was rejected without further comment, which going by the article wasn't the case. So his opinion of the maintainer is at best misinformed, at worst intentionally deceptive.
Also going by the article a merge can be forced by the committee. So this seems to be a non issue.
Re: Debian still having trouble with merged /usr
#233Earlier quoted context omitted.
> It is because on old Unix systems there frequently wasn't enough space to store /usr on the root disk. It was really a single system in 1971 that kicked off this trend. Originally /usr was for user files, like /home is today (do you'd have /usr/dmr, /usr/ken, etc.) / and /usr were two physical disks, and at some point the / disk (a 1 or 2MB disk IIRC) was full to they put some things from /bin in /usr/bin as a hack…
Is that also where /usr/share got its name for application data? Data that's shared among the rest of the users, as opposed to in their respective homedirs?
share is for architecture-independent data (ie data which is “shared” by all architectures). Executable binaries are not shared, but things like man pages are.
Re: Debian still having trouble with merged /usr
#234Earlier quoted context omitted.
It should also be noted that, while this change is Linux-specific, it does not directly break software which also targets BSD or nix-like OSs. Files that were previously in /usr/bin or in /bin can now be found in EITHER of these locations, since one symlinks the other. So no previous expectation was really broken. Only software built on merged systems fails to run on unðmerged systems. This should not really happen,…
> Files that were previously in /usr/bin or in /bin can now be found in EITHER of these locations, since one symlinks the other. So no previous expectation was really broken. I don't know, I just hit breakage the other day. I have /usr/bin before /usr in my path (which is the default on Ubuntu at least); I have muscle memory to use dpkg -S `which $foo` to figure out which package a binary is, but that doesn't work if…
This is a _very_ clear P.O.V.:
Who installed '/foo/bar/baz' when '/foo' is a symlink to '/usr/bin'?
I'm 100% in favor of the DPKG maintainer's perspective of "do ugly symlink farms" and then "reap what you sow" (ie: if you don't like there being a symlink there, then fix the offending package).
Re: Debian still having trouble with merged /usr
#235I'm surprised that they are pushing to remove /bin and keep /usr/bin. Why not the other way round? Let's keep our binaries out of /usr! (as a first step to remove /usr altogether, since it has a confusing name). I long for a day where PATH=/bin is all we need.
That is surprising. Just /bin with a /usr/bin->/bin symlink is common in embedded systems. I doubt the symlink is even necessary in most of those.
Re: Debian still having trouble with merged /usr
#236As a Debian user in a previous life, and a current NixOS user, this whole debacle amuses me greatly, as I no longer give a shit about paths like /usr/bin or /bin, beyond a handful of binaries needed to bootstrap my environment. I've even moved those paths into a read-only filesystem on some systems!
Re: Debian still having trouble with merged /usr
#237I thought Apple sort of did this already? (I know, OS X is not Linux.)
Re: Debian still having trouble with merged /usr
#238Re: Debian still having trouble with merged /usr
#239Earlier quoted context omitted.
How much of Python's success is down to the BDFL(-delegate) approach of governance? It seems a lot of projects have adopted it and Python's PEP system for managing new features. I wonder if Debian could use a similar sort of elected presidential system.
I mean, C++ is designed by committee, and it's hard to deny that it's been pretty successful too, regardless of what people's opinions on the language are. Both styles have flaws, but both can be adequate if you put in the right incentives and the right people.
I'm not sure the success of C++ has as much to do with the C++ committee as the fact that there were few alternatives competing in the same space until the past decade.
Re: Debian still having trouble with merged /usr
#240Earlier quoted context omitted.
I mean, C++ is designed by committee, and it's hard to deny that it's been pretty successful too, regardless of what people's opinions on the language are. Both styles have flaws, but both can be adequate if you put in the right incentives and the right people.
I'm not sure the success of C++ has as much to do with the C++ committee as the fact that there were few alternatives competing in the same space until the past decade.
I didn't say it's due to the committee, I just said it succeeded and had a committee. Python succeeded and had a BDFL, but I wouldn't say it's due to that either - lots of projects pull off the latter but not the former.