Bug#1050001: Practical problems with proposed symlink farming: diversions
On 2023-09-01 Ansgar wrote: > Hi, > a practical thing with usrmerge and legacy layout[1] is the following: > assume you do not want programs to find a specific program via PATH > lookup or even a fully-qualified path. > Then a user can just divert that single program away (or just remove > it, depending on details). > With Jackson's proposed symlink farms this property goes away: > users now have to handle both the copy in / and /usr! [...] Hello, I do not think this is the case. A) The proposed /bin/ will not contain symlinks for everything in /usr/bin but just for files that used to live there. I am not sure how common it is to divert one of this subset in the first place. B) I Think diverting the real file in /usr/bin would be enough, the now broken symlink in /bin should not be found by normal path search - At least that is true for bash, dash and tcsh, also test -x does not succeed on the symlink. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
On 2022-09-27 Zack Weinberg wrote:
[...]
> What I am asking for is a schedule change: specifically, that the
> merged /usr transition not be allowed to proceed past the status quo
> as of two weeks ago (i.e. *before* init-system-helpers added a
> dependency on usrmerge|usr-is-merged) until after the dpkg bugs are
> fixed to the satisfaction of the dpkg maintainers.
[...]
Hello Zack,
Afaiui the only thing the change two weeks caused is an increased
percentage of usrmerged Debian installations.
Afaict the problem is unchanged: There is a very large number of
usrmerged systems (every system installed with bullseye installer or
newer unless some very specific steps were taken to avoid this) which
are prone to bugs due to dpkg not having been changed *first*. This
number is of usrmerged systems is so large that we cannot mark them as
unsupported ("Please reinstall"). Whether this percentage is 25% or 90%
does not matter.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Bug#975381: Subject: libinih: drop Debian's custom vendorisation
On 2020-11-21 Stephan Lachnit wrote: [...] > Because the library was designed for embedded use cases where every > little bit of performance matters, the runtime patch was refused > upstream. Dropping the runtime patch from Debian actually isn't > problem, no reverse dependency of libinih uses compile time options > anyway. Hello, goxel does.[1] goxel-0.10.6/src/utils/ini.h:#define INI_HANDLER_LINENO 1 and gnutls would, too. So imho inih upstream needs a interface that allows linking either dynamically against system libinih or statically against the included copy without changing the source with something equivalent to the compile time options. The current Debian-patched version requires source changes depending on what linkage is targeted, upstream's version of the dynamic library just does not work when these compile time options are needed. cu Andreas [1] Which is probably why it actually uses the static copy although it depends on libinih. (#978021) -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#727708: Thoughts/Summary on the init-system
On 2014-01-19 Andreas Barth a...@ayous.org wrote: [...] On the linux ports, all would work. On the kbsd ports I believe that both upstart and openrc could be working, but none is yet. For hurd, at least openrc could and probably also upstart. Porting systemd to kbsd or hurd is not realistic from what I understood [...] I don't believe that it would work long-term if we use systemd on Linux and upstart on !Linux. [...] All of that together boils down to these options for the default pid1-provider / runlevel manager (perhaps after some more porting in this cycle): 1. Systemd on Linux, openrc/sysv-rc on non-Linux 2. Upstart everywhere (3. openrc/sysv-rc everywhere - as both systemd and upstart are better, I don't think this ends high enough on my priority list; see below for details) [...] Now, putting that all together, from the options above systemd for Linux, openrc/sysv-rc for !linux or upstart everywhere I prefer the upstart choice. Reasons for this see many details above, supporting all the required features, not as invasive in the debian system, saving us to integrate more than one init system reasonably well etc. [...] Hello, could you provide a little bit of background why you consider both Systemd on Linux, openrc/sysv-rc on non-Linux and Upstart everywhere viable long-term but not systemd on Linux and upstart on !Linux? thanks, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119181526.gj3...@downhill.g.la
