@juliank - *my suggestion is use variables in apt, which provides an
option. It's not forcing a design decision of how it must be done.
Fedora/RHEL is a good example of where it works and dispels your empty
argument that it causes a terrible user experience.
However, based on your comment, the dis
@juliank - my suggestion is use variables in apt provides an option.
It's not forcing a design decision of how it must be done. Fedora/RHEL
is a good example of where it works and has dispels your empty argument
that it causes a terrible user experience.
However, based on your comment, what disagr
Public bug reported:
apt sources conventionally use a fixed release name. But this causes
both adding repos as well as upgrading an unnecessarily painful
experience. For instance, adding a simple package requires adding the
keys with `apt-key` and then adding the repo, and then apt update/apt
inst
** Package changed: procps (Ubuntu) => ubuntu
** Description changed:
Currently,
`$ sysctl kernel.core_pattern`
gives
`kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P`
This should be considered a bug, since a minimal version of ubuntu
(server, core etc) and
** Description changed:
Currently,
`$ sysctl kernel.core_pattern`
gives
`kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P`
- This should be considered a bug, since a minimal version of ubuntu or
- even debian, and more notoriously when run from containers, this wi
Public bug reported:
Currently,
`$ sysctl kernel.core_pattern`
gives
`kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P`
This should be considered a bug, since a minimal version of ubuntu or
even debian, and more notoriously when run from containers, this will
just error out, with
6 matches
Mail list logo