xcat2 / xcat-core

Code repo for xCAT core packages
Eclipse Public License 1.0
372 stars 173 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.

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 8 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 8 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.

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:

Which one do you prefer?