Is there a way to merge several RPMs

[voxik]

This is related to #2849 (comment). Given there are a.rpm and b.rpm packages, is there a way to merge them into package c.rpm (or merge b.rpm into a.rpm, it does not matter).

[ffesti]

Short answer: No
Longer answer: No, but one could create one, but you really do not want to.
Other answer: Yes, but no the way you want.

[ffesti]

Even longer answer: One could create a tool to do that with the rpm API. But I really don't see a a reason to do so. You are also kinda confused about RPMs and SRPMs. I don't think you really want to merge binary RPMs but get rid of packages in distgit - which is the expensive part as far as I see it.
If you do want to merge binary packages (not that I can think of a good reason) use meta packages instead.

Merging Spec files is a different thing completely. That is probably something to look into - especially if they can be created automatically from gems or similar language specific package formats.

[voxik]

You are also kinda confused about RPMs and SRPMs.

I don't think I am. Or at least I don't know why you think so.

One possibility I can think of is that if the RPMs should be mergeable, then probably also SRPM should be mergeable for consistency? That would be likely weird, not sure 🤷

I don't think you really want to merge binary RPMs but get rid of packages in distgit - which is the expensive part as far as I see it.

Maybe or maybe not. I am looking for options.

If you do want to merge binary packages (not that I can think of a good reason) use meta packages instead.

This is not an option in this context. One way or the other, it adds one more package.

Merging Spec files is a different thing completely. That is probably something to look into - especially if they can be created automatically from gems or similar language specific package formats.

This is what I thought would be the hard part 😆 Maybe mainly because I don't see a merit in merging spec files like just plain concatenating and obtaining the same result. It would probably be interesting, if I can select some sections, while probably modify the associated %files section.

[ffesti]

You are also kinda confused about RPMs and SRPMs.

I don't think I am. Or at least I don't know why you think so.

That's what a confused person would say...

Merging RPMs and SRPMs is not something we will pursue and it doesn't make any sense. There is no point in merging SRPMs as they can only have one spec file each.

If you do want to merge binary packages (not that I can think of a good reason) use meta packages instead.

This is not an option in this context. One way or the other, it adds one more package.

I have not yet seen an argument why the number of packages is a problem.

Merging Spec files is a different thing completely. That is probably something to look into - especially if they can be created automatically from gems or similar language specific package formats.

This is what I thought would be the hard part 😆 Maybe mainly because I don't see a merit in merging spec files like just plain concatenating and obtaining the same result. It would probably be interesting, if I can select some sections, while probably modify the associated %files section.

This is the only thing here that is actually worth considering here. It would kinda fit into both the Dynamic Spec and the Handsfree Packaging initiatives. Basically dropping multiple gems into a single distgit package and assemble the merged spec file automatically. There are probably still a few pieces missing but we already made big steps into making this possible.

[voxik]

You are also kinda confused about RPMs and SRPMs.

I don't think I am. Or at least I don't know why you think so.

That's what a confused person would say...

🤣 🤦‍♂️ 🤷

Merging RPMs and SRPMs is not something we will pursue and it doesn't make any sense. There is no point in merging SRPMs as they can only have one spec file each.

If you do want to merge binary packages (not that I can think of a good reason) use meta packages instead.

This is not an option in this context. One way or the other, it adds one more package.

I have not yet seen an argument why the number of packages is a problem.

There was modularity, but it is not anymore. Now I am thinking what to use instead.

In the case of Ruby, the module consisted of Ruby and DB connectors. We can simplify this into having ruby and rubygem-pg SRPMs, which in it full fledge state builds into gazillion RPMs subpackages, and call it "default Ruby".

Now I am considering options how to deliver some alternative version. One of the options is lump everything together and deliver it as a single RPM (instead of all the subpackages which "default ruby" consists of). Of course I could ignore everything what is already available and start from scratch. The other option is to try gather various bits and pieces and try to reuse them.

Merging Spec files is a different thing completely. That is probably something to look into - especially if they can be created automatically from gems or similar language specific package formats.

This is what I thought would be the hard part 😆 Maybe mainly because I don't see a merit in merging spec files like just plain concatenating and obtaining the same result. It would probably be interesting, if I can select some sections, while probably modify the associated %files section.

This is the only thing here that is actually worth considering here. It would kinda fit into both the Dynamic Spec and the Handsfree Packaging initiatives. Basically dropping multiple gems into a single distgit package and assemble the merged spec file automatically. There are probably still a few pieces missing but we already made big steps into making this possible.

Nice. Still to me, merging RPMs sounds easier then merging .spec files. To me, merging RPMs happens every time two RPMs are installed. Of course I ignore metadata. But I have never heard of merging .spec files.

[pmatilai]

I guess what you mean by "merging" is something entirely different than me & ffesti think of.

Binary rpm's are immutable end products of a spec which directs rpmbuild to produce said rpms. Somehow undoing a separation set by the packager is just not a meaningful operation at all. The only meaningful merge in rpm land is something a packager does, at a spec/srpm level.

[voxik]

I guess what you mean by "merging" is something entirely different than me & ffesti think of.

In my naive view, I see binary RPM as nothing more then (fancy) tarballs. And combining two tarballs is legitimate operation AFAIK, given there is tar --concatenate option.

Binary rpm's are immutable end products of a spec which directs rpmbuild to produce said rpms. Somehow undoing a separation set by the packager is just not a meaningful operation at all. The only meaningful merge in rpm land is something a packager does, at a spec/srpm level.

I see it differently. If you abstract away, then several merged RPMs gives you e.g. container image (Yes, I have deliberately removed a lot of complexities).