[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH for-xen-4.5] tools/mkrpm: improve version.release handling
On Mon, Nov 3, 2014 at 2:48 PM, Olaf Hering <olaf@xxxxxxxxx> wrote: > On Mon, Nov 03, George Dunlap wrote: > >> On 11/03/2014 02:24 PM, Olaf Hering wrote: >> >On Mon, Nov 03, George Dunlap wrote: >> > >> >>How difficult would it be to have this be something sensible like, >> >>"changesets since last tag"? >> >Very difficult, because one does changes without commit, runs 'make >> >rpmball' and expects that rpm -Fvh *.rpm continues to work. >> >> Right. Personally, I think trying to make "rpm -Fvh" work for all the use >> cases a developer might want is more hassle than it's worth; as I said, I >> have scripts that just do "rpm -e" in such cases. I wouldn't oppose it, but >> I don't really support it either. > > What exactly is the hassle here?! Its just some number for the sake of > rpm. A number based on the time you happened to create the RPM, not based on something intrinsic about the content of the RPM; that just seems kind of hacky to me. It happens to work well for your common workflow, but you can certainly imagine other workflows or other situations where you'd have to more manually override things anyway (for instance, doing bisections, or comparing functionality in different releases). It seems like rather than having to remember when you can skip the manual override bits, and when you can't, it would be better to just use them all the time. Anyway, like I said, I won't argue against it. I have no technical objections to the patch; it seems to do what it says on the tin. I'll leave it for the maintainers to decide what they think about the functionality. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |