#500 Let's have a way to define in spec file some package is multilib
Closed: Invalid 5 years ago Opened 7 years ago by praiskup.


But what if you want some package to have multilib in one variant, but not in another one?

Could %multilib_package server workstation help? Resulting in this
artificial provides:

Provides: multilib(%name[!][variant[|variant ...]]) = %version-%release

In practice, this would be the "output":

# Two variants
Provides: multilib(quick-package:server|workstation) = 20170106_1036-0.fc25
# All variants
Provides: multilib(quick-package) = 20170106_1036-0.fc25
# Exclude cloud and server
Provides: multilib(quick-package:!cloud|server) = 20170106_1036-0.fc25

That's just raw idea.

Please note I don't propose to drop the autodetection immediately, just that such explicit statements should have higher priority.

@lsedlar When you say "variant" do you mean "Server Edition vs Workstation Edition", or do you mean "x86_64 vs. ppc64"?

@sgallagh in pungi a variant is Server vs Workstation, vs Spins, vs Labs etc

I am against something that adds extra needless metadata. the repodata for Everything today is around 50Mb it is way too big this would add extra fields that need to be in the repodata in order for multilib to be resolved. multilib today is a x86_64 only thing that I would much rather solve by some other mechanism. potentially enabling i686 repos on x86_64

@ausil I agree, I was mostly asking to make sure we were using the same terminology to mean the same things.

FWIW, I very much doubt that we'd want different multilib settings on different variants, because that would needlessly complicate things. Right now, they can all just use the same metadata and repos.

I am against something that adds extra needless metadata.

The issue is that in postgresql-odbc (and mysql-connector-odbc) some additional metadata is needed, otherwise pungi makes a bad decisions. If we want postgresql-odbc to be a multilib package, how should we do it?

multilib today is a x86_64 only thing

Is this truth for RHEL, too?

@praiskup file an issue in the releng pagure instance or pungi-fedora we can adjust the multilib policy, we will also need to make mash adjustments for updates as well

Btw. I really doubt adding something like this into multilib only (binary) RPMs (in Fedora case we talk only about a small i686 package subset) would change size of the whole metadata payload.. do we have estimation? If we really cared, we could have this specified in source rpm only, or possibly we could drop that info from the final repo metadata (as nothing else than pungi has use for it).

multilib today is a x86_64 only thing

Is this truth for RHEL, too?

it will be going forward. multilib still exists in RHEL, but not epel for ppc64 in rhel 7.

epel does not support multilib at all

@praiskup file an issue in the releng pagure instance or pungi-fedora we can adjust the multilib policy, we will also need to make mash adjustments for updates as well

https://pagure.io/pungi-fedora/issue/124, thanks - but changing policy because of specific package sounds wrong to me, do I have to make sure that this will be inherited by RHEL/CentOS pungi later?

Btw. I really doubt adding something like this into multilib only (binary) RPMs (in Fedora case we talk only about a small i686 package subset) would change size of the whole metadata payload.. do we have estimation?

You would add one provide per. multilib. package, so:

total packages on x86-64: ~52k
i?86 multilib packages: ~8k (~15.4%)
total provides: ~350k

...so the simple way (new provide goes in both arches) would add ~5% to provides data ... at a super rough guess provides are 10-20% of the data for a package ... so a 0.5%-1% increase in primary size?

All untested.

Doesn't sound that bad to me (compression is not taken into account, only one arch among multilib compatible arches needs this)

Seems like we can not add arbitrary "PROVIDES" metadata into SRC.RPM, yet. I tried to file rhbz#1411629, but that's long shot. I'm not sure, would it make sense to be able to drop some metadata from repository? But pungi only analyses the repository, not the RPMs, right?

News for me, so FTR: RPM has long-time opened bug https://bugzilla.redhat.com/show_bug.cgi?id=653744 discussing something similar.

https://pagure.io/pungi-fedora/issue/124, thanks - but changing policy because of specific package sounds wrong to me, do I have to make sure that this will be inherited by RHEL/CentOS pungi later?

CentOS does not use pungi, they have their own tooling. multilib policies in RHEL are determined by PM not developers afaik.

CentOS does not use pungi, they have their own tooling.

Why?

multilib policies in RHEL are determined by PM not developers afaik.

This is IMO not an issue; adding package or sub-package is also
determined by PM.

CentOS does not use pungi, they have their own tooling.

Why?

you would have to ask them.

multilib policies in RHEL are determined by PM not developers afaik.

This is IMO not an issue; adding package or sub-package is also
determined by PM.

Just saying what is done in Fedora may not be accepted into RHEL.

Why?

you would have to ask them.

Yeah, it is neither my issue ... but I suspect the reason is that pungi is not flexible enough ... and there's no official api for multilib detection.

Just saying what is done in Fedora may not be accepted into RHEL.

I'm now more interested in fixing this in Fedora TBH.

I'm going to close this issue. Pungi can not change if multilib information is stored in spec. If you still want this to happen, a bigger discussion needs to happen with release engineering and RPM team.

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

5 years ago

Login to comment on this ticket.

Metadata