rpm spec file conflicts syntax query

[gazzo]

Hi Guys,

I am new to Linux/rpm & the forum so please bear with me.

I have inherited our Linux packaging and as the number of versions increase, the number of conflicts is starting to get a bit unmanageable.

I believe the easiest way would have been to keep the package names the same and just change the release in the spec file but unfortunately I am past that as a lot of these packages are rolled out to our estate. (I am told there were reasons for not keeping the package name the same and incrementing the version/release)

Is it possible to wildcard conflicts so I don't need to keep adding as new versions are created.

For example, instead of using all the conflicts below, have something along the lines of AAtest45* <= 1.4 & BBtest45* <= 1.4

Meaning that all I would need to do was change this to 1.5 at the next release (the packages below version matched the release in the spec file)

Conflicts: AAtest45_DEV, AAtest45_UAT, AAtest45_PRD, AAtest45v2_DEV, AAtest45v2_UAT, AAtest45v2_PRD, AAtest45v3_DEV, AAtest45v3_UAT, AAtest45v3_PRD, BBtest45v2_DEV, BBtest45v2_UAT, BBtest45v2_PRD, BBtest45v3_DEV, BBtest45v3_UAT, BBtest45v3_PRD, AAtest45v4_DEV, AAtest45v4_UAT, AAtest45v4_PRD

Any assistance would be greatly appreciated. My apologies if I have not provided enough information.

[Irithori]

Well, there is a good, bad and a ugly part.

The good:
You are right.
Package names should stay the same,
Version and Release can change.

And guess what: < and > will work for versions


The bad:
Apparently packages were already released in that sorry state.

Not exactly sure, what your workflow looks like.
We run three channels via spacewalk:
dev, rc and production.
- dev channel is only a way for devs to have a central place for exchanging rpms.
- rc channel is for the QA guys. Once packages are synced here, the apps within them will be tested for errors.
If there are any -> new build.
- if the rc packages have been signed off then they will be synced to production.

So yes, the same package (and code) is in rc and in production.
Which is a requirement at my place.
The code needs to be tested before release.

And as a sidenote:
Configurations shall *not* be handled via RPMs.
Wrong tool.
You can include a generic config and/or templates.
But *no* environment specific confs.

Configs are a different topic and can be handled by for example cfengine or puppet.


The ugly:
As a consequence, you might have to address that and therefore challenge an old (but wrong) practice as your first thing as "the new guy"

I wish you good luck.

[gazzo]

Thank you.