#823 introduce increasing prefix to disttag hash
Closed: Fixed 6 years ago Opened 6 years ago by ignatenkobrain.

It complicates DNF implementation of modules quite a lot and makes things not user-friendly. Is there any reason not to use timestamp instead?


For example, look at

--- Listing Modules ---
Available Modules                                                              
NAME                                              STREAM VERSION
nodejs                                            6      2017.10
├─nodejs-1:6.12.0-1.module_99999999.x86_64               
└─npm-1:3.10.10-1.6.12.0.1.module_99999999.x86_64        
nodejs                                            6      2017.12
├─nodejs-1:6.12.0-1.module_00000000.x86_64               
└─npm-1:3.10.10-1.6.12.0.1.module_00000000.x86_64        
nodejs                                            8      2017.11
├─nodejs-1:8.9.1-1.module_deadbeef.x86_64                
└─npm-1:5.5.1-1.8.9.1.1.module_deadbeef.2.x86_64         

--- (modular) dnf install npm (no defaults) ---
Installed:
  - glibc-2.26-20.fc27.x86_64
  - module:nodejs-8-8-2017.11.x86_64
  - nodejs-1:8.9.1-1.module_deadbeef.x86_64
  - npm-1:5.5.1-1.8.9.1.1.module_deadbeef.2.x86_64

--- (modular) dnf install npm @nodejs:6:2017.10 (nodejs:6 is default) ---
Installed:
  - glibc-2.26-20.fc27.x86_64
  - module:nodejs-6-6-2017.12.x86_64
  - nodejs-1:6.12.0-1.module_00000000.x86_64
  - npm-1:3.10.10-1.6.12.0.1.module_00000000.x86_64

--- (modular) dnf install npm @nodejs:6:2017.10 (to enforce older version) ---
Installed:
  - glibc-2.26-20.fc27.x86_64
  - module:nodejs-6-6-2017.10.x86_64
  - nodejs-1:6.12.0-1.module_99999999.x86_64
  - npm-1:3.10.10-1.6.12.0.1.module_99999999.x86_64

--- (modular) dnf update ---
Downgraded:
  - nodejs-1:6.12.0-1.module_99999999.x86_64 -> nodejs-1:6.12.0-1.module_00000000.x86_64
  - npm-1:3.10.10-1.6.12.0.1.module_99999999.x86_64 -> npm-1:3.10.10-1.6.12.0.1.module_00000000.x86_64
Upgraded:
  - module:nodejs-6-6-2017.10.x86_64 -> module:nodejs-6-6-2017.12.x86_64

--- (modular) dnf install @nodejs:8 ---
Upgraded:
  - nodejs-1:6.12.0-1.module_00000000.x86_64 -> nodejs-1:8.9.1-1.module_deadbeef.x86_64
  - npm-1:3.10.10-1.6.12.0.1.module_00000000.x86_64 -> npm-1:5.5.1-1.8.9.1.1.module_deadbeef.2.x86_64
Installed:
  - module:nodejs-8-8-2017.11.x86_64
Erased:
  - module:nodejs-6-6-2017.12.x86_64

Even module version increases, rpm versions are decreasing which makes whole DNF UI very complicated.

Using hashes in the dist tag were basically there to ensure differentiation in case two modules ended up with the same package version, but built against different buildroots.

With the hybrid model that's been proposed, we know that the buildroots will be the same, so we don't need this functionality at all (and in fact probably don't even need the timestamp approach).

Based on conversation in the productization cabal today, we do still need the hash for differentiation in some cases, but not the majority.

I'd prefer to implement a prefix to the hash for now, instead of dropping it.

The prefix needs to be guaranteed to be increasing, but may have gaps in the series. With due respect, I'm going to commandeer this ticket to be only about introducing the increasing prefix. Let's take up the complexities of when we can and cannot drop the hash all-together in a separate ticket. Will rely on @sct to file that ticket and describe the case.

In what context should the prefix increase? Per builds of particular NVR in single module's "name:stream"?

Based on conversation in the productization cabal today, we do still need the hash for differentiation in some cases, but not the majority.
I'd prefer to implement a prefix to the hash for now, instead of dropping it.
The prefix needs to be guaranteed to be increasing, but may have gaps in the series. With due respect, I'm going to commandeer this ticket to be only about introducing the increasing prefix. Let's take up the complexities of when we can and cannot drop the hash all-together in a separate ticket. Will rely on @sct to file that ticket and describe the case.

Does this mean that for every module build in the same stream, the prefix would increment which would show which one was built later?

In what context should the prefix increase? Per builds of particular NVR in single module's "name:stream"?

Yes, I think that's right.

Does this mean that for every module build in the same stream, the prefix would increment which would show which one was built later?

Yes.


For any module build in a name-stream, we could query the db for the .count() of module builds in that name-stream. Take that integer and prefix the dist-tag hash with it.

FYI, this relates to an older issue #494.

Just clarifying on request --- as Ralph mentioned above, there are really two requirements here.

One is that newer versions of a module in a stream must have higher NVR in all their RPMs than older versions. This is to support some dnf use cases around cherrypicking updates into a separate repository; the update behaviour becomes undefined or inconsistent if modulemd and NEVRA have different views over which rpm is the latest.

Using a timestamp instead of a hash would be one natural way to do that, though it's not the only way.

The second is to skip the suffix entirely when it is not needed, but that second requirement is lower priority, and is cosmetic and for simplicity of UX only. A natural solution would be to skip the timestamp addition if this is the first build of a given spec/NVR. I'm fine with keeping this part as a separate ticket.

Metadata Update from @mprahl:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata