[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.