#46956 closed enhancement (fixed)
base should keep track of explicitly requested variants on install and only preserve those on upgrade
| Reported by: | neverpanic (Clemens Lang) | Owned by: | neverpanic (Clemens Lang) |
|---|---|---|---|
| Priority: | Normal | Milestone: | MacPorts 2.7.0 |
| Component: | base | Version: | 2.3.3 |
| Keywords: | Cc: | mojca (Mojca Miklavec), larryv (Lawrence Velázquez), dliessi (Davide Liessi), ci42, cooljeanius (Eric Gallager) | |
| Port: |
Description
Base currently tries to preserve all installed variants when upgrading a port. In the case of version choice variants (such as perl5_16, llvm33, ...) this leads to a situation where a user does not actively choose a variant when installing, but the variant is still preserved even when the port's default variant changes later on. Users no longer get binary archives for these non-default variants and generally end up on rather outdated systems. We should modify MacPorts to only preserve variants that have been explicitly requested.
To do that, I propose we add a new database field requested_variants to the ports table of the registry. It should have the same format as the currently available variants and negated_variants field (which could, IMHO, be merged into one). The installation code should be modified to store the list of variants explicitly requested on the command line in this field. The upgrade code should also be modified to preserve the list of requested variants, not the list of all variants of a port.
A couple pointers to a possible implementation:
- The database field would have to be added along with an upgrade path in source:trunk/base/src/cregistry/sql.c
- The registry sqlite access code should be modified to support the field, in source:trunk/base/src/registry2.0/entryobj.c
- The registry API should be modified to support passing the field, in source:trunk/base/src/registry2.0/receipt_sqlite.c
- The macports installation and upgrade routines should be modified as described above, in source:trunk/base/src/macports1.0/macports.tcl, source:trunk/base/src/port1.0/portinstall.tcl
Change History (12)
comment:1 Changed 10 years ago by neverpanic (Clemens Lang)
| Cc: | cal@… removed |
|---|
comment:2 Changed 10 years ago by mojca (Mojca Miklavec)
| Cc: | mojca@… added |
|---|
comment:5 Changed 8 years ago by mojca (Mojca Miklavec)
I wanted to point out a somewhat related "problem" reported in #51498.
comment:6 Changed 8 years ago by ci42
| Cc: | ci42 added |
|---|
comment:7 Changed 7 years ago by neverpanic (Clemens Lang)
| Milestone: | → MacPorts 2.6.0 |
|---|
comment:8 Changed 7 years ago by neverpanic (Clemens Lang)
| Owner: | changed from macports-tickets@… to neverpanic |
|---|---|
| Status: | new → accepted |
comment:9 Changed 7 years ago by mojca (Mojca Miklavec)
| Milestone: | MacPorts 2.6.0 → MacPorts 2.7.0 |
|---|
comment:10 Changed 4 years ago by cooljeanius (Eric Gallager)
| Cc: | cooljeanius added |
|---|
comment:11 Changed 4 years ago by jmroot (Joshua Root)
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
comment:12 Changed 4 years ago by neverpanic (Clemens Lang)
Thanks. I wanted to fix this before bringing port migrate to mainline, so that it'll only preserve requested variants (since otherwise guessing which variants you actually wanted, and which ones you didn't is quite complicated).
Could you write a Changelog entry and document how the conversion from current state to requested variants works?
Cc Me!