Automatically use sed(1) to remove DOS line endings from .cabal files.
This is intended to work around Hackage producing revised cabal files
with DOS line endings (https://github.com/haskell/hackage-server/issues/316).
This frequently leads to
- patches failing to apply. Unfortunately there is no way to apply a
patch with Unix line endings to a file with DOS line endings with
GNU patch(1). Only the following combinations are supported:
file patch comment
Unix Unix
DOS DOS using --binary
DOS Unix Haven't tested it, but I assume it works because
patch(1) converts the file to Unix line endings
implicitly (which can be disabled using --binary),
but never the patch…
- Test suites sometimes involve the .cabal file which can be
affected by the line endings.
This behavior is enabled by default to prevent cases where (unrevised)
packages regress when they get a revision later. Of course, the behavior
is a little nonsensical for non-Hackage packages, but it is probably
rarely an issue in practice. When DOS line endings need to be preserved,
the user can pass `dontConvertCabalFileToUnix = true`.
Supersedes #279248.
Resolves#206840.
See 1e71cad6e4/maintainers/scripts/pluginupdate-py/pluginupdate.py (L487).
This line checks the plugin's name and normalizes it before checking with `to_update`.
`to_update` is a raw list of packages you want to update.
Thus, calling `vim-plugins-updater update "package-name"` filters `current_plugin_specs`, removing all `PluginDesc` with *normalized* names that do not match `to_update`
Hence, updating something like "mini.nvim" does not work as the filter expects normalized names. Using "mini-nvim" instead works as intended
GDC 11 was the last version that could bootstrap without a D compiler,
and GDC don’t offer their own binaries any more. GCC 11 is now
end‐of‐life and being removed (as is GCC 12, even).
It’s possible that we could use another distribution’s binary
packages to bootstrap this, or go via our DMD package (it’s
apparently not possible to bootstrap GDC with LDC, but I’m not sure
about DMD), but as nobody has worked on it in the three years since
GCC 12 came out, it seems like interest is limited, and it’s more
of a yak shave than I’m up for right now.
A full from‐source bootstrap chain would of course be nice, but is
more the realm of the minimal bootstrap work than something we’d
want to keep GCC 11 around in the main package set indefinitely for.
