----- Original Message -----
> From: "Matthew Miller" <mattdm@xxxxxxxxxxxxxxxxx>
> To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Tuesday, October 8, 2019 9:18:29 AM
> Subject: Re: Modularity and the system-upgrade path
>
> On Mon, Oct 07, 2019 at 08:08:56PM -0400, Alexander Scheel wrote:
> > > Without modularity, RPM doesn't offer a good way to choose between
> > > different
> > > versions of the same thing. One can squash version numbers into the name,
> > > which covers some use cases, but also becomes unwieldy and loses the
> > > _idea_
> > > that these things are different branches of the same basic software.
> >
> > This is not true at all.
> >
> > For starters, if you have parallel packages available [0], `rpm -i` will
> > let you install them all just fine and track each individually [1]. When
> > you go to uninstall it (`rpm -e rpm-test`), it'll complain that you didn't
> > specify which one [2], so you'll of course have to specify a version [3].
> >
> > If you then go stick it in a repo, DNF will show you the highest version,
> > which is expected since DNF generally concerns itself with the updated-ness
> > of your system [4]. But you can always pass --showduplicates to show the
> > older versions. And nothing prevents you from selecting a different version
> > of the package if they exist in the repo [5]. The one place this fails
> > is that DNF will perform an upgrade, removing the older version, even if
> > you
> > choose install [6].
>
> What if you want to apply a bugfix (or security update) to both of those
> packages? How would that work?
I'm not saying it is completely solved, just that what we have left to
do is a lot less work than trying to fix modularity. [0] :)
Since you asked... :)
That's where you apply the dnf intent mechanism (iirc) this thread brought
up, except it is a lot simpler because it operates on packages, which are
single, relatively atomic units instead of modules, which are globs of special
packages.
There's four cases here (assuming a two-part version):
- dnf install rpm-test # just a package name
---> no versionlock under the hood
- dnf install rpm-test-1 # partial version -- major version 1
dnf versionlock rpm-test>=1
dnf versionlock rpm-test<2
^ user has said, I want any major version 1 of this package,
and I'll take any minor releases or patch updates.
- dnf install rpm-test-1.0 # full version -- major version 1, minor version 0
dnf versionlock rpm-test>=1.0
dnf versionlock rpm-test<1.1
^ under a two-part version scheme, this locks the user into only receiving
patch updates. This is strict user intent, but we might want to confirm
that they agree to receive only patch updates and might miss important
bug fixes and some security fixes.
- dnf install rpm-test-1.0-1 # full name, version, and release
dnf versionlock rpm-test-1.0-1
^ this is even stricter and prevents any new patch versions.
I'd probably add a message to DNF update showing what packages won't be
upgraded by a specific policy. And, since it all lives in the versionlock
DNF plugin, there's a very well-known, easy way to modify these locks,
which you'd also have to provide for modularity intents. I'd probably make
it a message with confirmation about all new version locks introduced in
a transaction and have the user manually confirm the batch separately from
confirming the install.
If the user wants to lock dependencies, once they're installed, they can
of course use versionlock here as well. Entirely up to them.
---
Bugfixes and security updates are the easiest to do. You'd have a version-based
dist-git branch for each of your packages:
- rpm-test:v1.0
- rpm-test:v1.1
- rpm-test:v2.0
Some policy dictates which releases ship where. So, a bugfix comes in as a patch.
The maintainer decides which branches to check it into (depends on the bug,
severity, and how well the patch applies to older versions). Since its a patch
release, everyone will get it.
Now let's say we get a bigger security flaw. It results in a partial rewrite
upstream, and isn't conducive to patching. Upstream releases v1.2 and v2.1.
I'd:
- Annotate it as a security fix in Bodhi,
- When dnf update runs:
- non-version locked systems get an update to v2.1,
- version-locked to any v2 get an update to v2.1,
- version-locked to any v1 get an update to v1.2,
- Any other version-locked message gets a warning on DNF upgrade
saying that they locked themselves out of receiving a security
update. Then, the community member can either loosen their
versionlock and get the update, or continue opt-out of receiving the
update at their own risk.
- System upgrade time will work just like a regular DNF update; if a
package versionlock is known to conflict, we can then decide on a
policy... removing versionlocks to old versions, requiring parallel
versions, &c. Ultimately, you'll probably encourage major-version locking
and have a major version overlap on most critical packages. It'll probably
work like the orphaned&retired package lists, where things get blacklisted.
Or we can design some other mechanism. Up to the community here. But think
about it now. :)
Since only packages with explicit versionlocks based on very explicit user
intent, most packages will continue to upgrade as expected. You could add
heuristics based on "if I version lock @ firefox-1.0, I probably also want
to version lock firefox-data-1.0" (and lock all subpackages of a single
SRPM to the same version), but that can be a later feature.
Point is, to get this to work requires:
- Minor changes to an existing DNF plugin,
- Lots of policy discussions,
- Changes to how composes &c work,
- Minor changes to tooling.
- No changes to packages in dist-git other than letting the maintainer
move their existing fedora branches to version-based branches. No
modulemd for one. :)
In particular, you don't need:
- A completely separate build system (MBS),
- A completely separate package grouping system (dist-git modules/)
- A way of integrating the two package systems (Ursa Prime),
- A new subcommand under DNF that behaves differently and
breaks system upgrade (dnf module ...)
- ...
Hell, you could probably even extend versionlock to be the database for
module streams and fixing upgrades. :D
Anyhow, that's my 2c pipe dream,
- Alex
[0]: From what I can tell, the MVP here would be to allow the DNF versionlock
plugin to support Requires-like constructs, e.g.,
`dnf versionlock 'rpm-test<2'`. Currently it only supports locking to a
specific NVR. You could probably invent a tilda operator for saying
"around this version spec":
`dnf versionlock 'rpm-test~2'` would lock you to `rpm-test>=2` and
`rpm-test<3`.
Then you need policy around what versions can get into a compose, how new
package versions get added to a repository (Bodhi), how older versions get
retired, &c.
>
> --
> Matthew Miller
> <mattdm@xxxxxxxxxxxxxxxxx>
> Fedora Project Leader
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
