Changes to the rpm naming number for xCAT RPMs broke running makerpm stand-alone

xcat2 / xcat-core

Code repo for xCAT core packages

Eclipse Public License 1.0

367 stars 172 forks source link

Changes to the rpm naming number for xCAT RPMs broke running makerpm stand-alone #1905

Open whowutwut opened 8 years ago

whowutwut commented 8 years ago

The changes made in a series of commits to changing the version number of xCAT RPMs, broke the makerpm command.
80de8b426cea81729105aa6106706a8a76c3307d, af79f7d2

The buildcore.sh script still works so it's not a big problem, but we should fix this.

[vhu@victorvm7 xcat-core]$ ./makerpm perl-xCAT
Building /home/vhu/rpmbuild/RPMS/noarch/perl-xCAT-2.12.3-snap*.noarch.rpm ...
error: File : No such file or directory

Just hangs there.

daniceexi commented 8 years ago

@whowutwut I don't like to adopt the rpm version and name change now.

We need to consider the name&version change very carefully since if the name is not in a proper way, we would put a lot of effort to handle the migration issue even we decide to change it back.
It's not safe to make the significant decision so close to the release.
With fixed release number will impact the update of snapshot build
Do we have plan to change the release number manually when make a new build? If no, the release number would not make any sense.

daniceexi commented 8 years ago

The code has the way to get to the date format of naming for packages, could we get back to the original naming format for 2.12.3 and consider the new format in next release?

whowutwut commented 8 years ago

@daniceexi Thanks for your comments. I agree you have some valid points.
Let's undo this for this 2.12.3 release and look more closely at this for 2.12.4...

I'll create a pull request to put the changes into the master branch, then disable the release tag so we go back to using the snap formatting.

whowutwut commented 8 years ago

The changes in #1915 resolves the breakage to makerpm because release is disabled. But I think we should still keep this issue around to fix the makerpm when we enable release.

whowutwut commented 7 years ago

@daniceexi Seems like we are not planning anytime soon to adopt a new naming convention for the xCAT rpms. Jarrod is able to build his versions based on the code change with the new convention, so should we just close this issue?

daniceexi commented 7 years ago

@whowutwut do we see the goodness to adopt the change that include git ID in the rpm name?

whowutwut commented 7 years ago

@daniceexi Yes, I do see some good in this.

allows us to know exactly which commits are in the RPM (without the need to install)
a lot easier to read than the snap format

The advantage of having the snap is that during development, I can build xCAT multiple times and be able to do a yum update on the RPMs, where a git commit numbering scheme would require a commit to git before a build could happen with a increased number.

However, this is not always a BAD thing because that means the developer must have tested with the code that is committed.. instead of committing after development... then tested code doesn't match what is commit to git, potentially causing problems. I have seen this happen,

daniceexi commented 7 years ago

@whowutwut Good. If we want to adopt this change, two options:

As you mentioned in the previous comment that for daily build we also adopt the commit ID in the rpm name to replace the snap date. In this way, we need to put effort to see how to do the release number bump up automatically.
Use a compromised way that keep the daily build to use the snap date in the rpm name.

Which one do you prefer?