Then if 'apt' nor 'landscape' can have viable change. The only other
workaround I can think of would be to modify the way USN database pickle
works to include dependencies for package with USN vulnerability to
avoid this situation like this at least for dependencies within the same
source package.
** Also affects: landscape-client (Ubuntu)
Importance: Undecided
Status: New
** Changed in: landscape-client (Ubuntu)
Status: New => Won't Fix
** Changed in: landscape-client (Ubuntu Xenial)
Status: New => Won't Fix
** Changed in: landscape-client (Ubuntu Bionic)
FWIW, the real approach would be to follow unattended-upgrades and write
a GPLed script that uses python-apt and adjusts the candidates. Then
(copy and? - no real idea how landscape works) invoke that on the
system.
--
You received this bug notification because you are a member of Ubuntu
Touch
** Changed in: apt (Ubuntu)
Status: Confirmed => Won't Fix
** Changed in: apt (Ubuntu Xenial)
Status: Confirmed => Won't Fix
** Changed in: apt (Ubuntu Bionic)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch
That workaround wouldn't work in Landscape for many configurations; we
can't assume pocket names as many use custom mirrors or repository
snapshots in which the pocket may not match.
It seems to me there is no simple way to resolve this automatically in
Landscape, but as that upgrade situation is
In the attempt to workaround that behaviour at least for Landscape USN.
Would it be doable to force the package upgrade in Landscape by pocket
instead of package version ?
Fetching the package list from the USN file, then instead of ordering a
specific version, just mentioning where to go to
# apt-get install --dry-run -t xenial-security systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libpam-systemd libsystemd0
Suggested packages:
systemd-ui systemd-container
The following
So the problem seems to be that landscape assumes that upgrading a
binary package with the same name as a source package yields a usable
result, instead of querying which binaries are installed from that
source and upgrading them.
Like source systemd has systemd and libsystemd, so we should have
The solver in EDSP form is intended for use by autopkgtest, as
autopkgtest really needs the ability to install stuff from proposed as
needed. It won't make for a general purpose solver.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
I disagree. Being strict about the policy is a good thing - it gives you
a predictable result.
That said, you could install zsh/release and that does do some switching
of candidates to make that work. I don't like that. It also does not
work entirely reliably. I just closed two or three of these
Another package scenario, using "zsh" this time:
$ apt-get install zsh=5.1.1-1ubuntu2
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apt (Ubuntu Xenial)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apt (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
13 matches
Mail list logo
