Em 05-04-2010 18:35, Michael Jennings escreveu:
> On Saturday, 03 April 2010, at 20:10:43 (+0100),
> Rui Miguel Silva Seabra wrote:
>
>> It's not unnecessary, quite the contrary if you like clean rpm
>> installations and are doing some work on a library requiring more
>> than once a day installations.
>>
>> I'm interested in knowing why you think this is not a problem, if
>> you have a better way to do it, please teach me.
>
> The spec files in SVN are for end users as well as developers, and we
> try to reach a reasonable middle ground between the two uses. It is
> far, far cleaner and simpler for we developers who do frequent RPM
> installs in the course of developing our software to simply add
> "--force" to the RPM install command.
I'm sorry, but that breaks the whole point of having clean software
installs.
It's definitely *not* a sane (in terms of package DB) replacement to the
proper usage of the release field.
As can be read from the man page, it can even have dangerous results:
--force
Same as using --replacepkgs, --replacefiles, and --oldpackage.
(...)
--replacefiles
Install the packages even if they replace files from other,
already installed, packages.
As to the POV of users, they expect an incrementing value (which is also
what the release field should/must have precisely so upgrades can be
done sanely) and even if they don't recognize instantly date+hourmin,
they surely recognize just as instantly an increasing value, so there is
no point to raising such scarecrows.
>> I'd also bet that 100% of people bright enough to recognize YYYYMMDD
>> instantly will recognize YYYYMMDDHHMM (it's even one of the
>> instantly recognized methods for setting the date in multiple
>> implementations of this command).
>
> There's no sense at all in arguing made-up statistics for which
> neither of us could provide evidence or proof either way. Suffice it
> to say that YYYYMMDD is standard snapshot format.
It's as made up statistic as claiming YYYYMMDD is a standard snapshot
format.
If these two arguments are the best you can get as an opposition to what
is to me a clearly more sane method, then I beg someone to please act as
a mediator/judge on the matter.
It's a real PITA to have to change locally the rpm specs and pay
attention to eventual C's that come up with svn update.
Rui
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
