On Apr 21, 2012, at 10:07 AM, Dmitry V. Levin wrote:
> On Sat, Apr 21, 2012 at 03:27:13PM +0400, Alexey Tourbin wrote:
>> There another option, however. For the reason which shall remain
>> nameless, I find it tempting to produce the new and incompatible
>> format without any clear signs of distinction. :-)
>
> Taking into consideration that the current format is already
> in use in Sisyphus for more than 1.5 years, introducing a "new
> and incompatible format without any clear signs of distinction"
> would be unwise.
>
Good: I knew you were sane ;-)
But while you are here, let me ask a different "compatibility"
question, about RPM not Alt.
Because of the (largely aesthetic) choice of "set:" as a syntax
marker for set:versions in statements like this
Requires: libfoo.so.1 >= set:yaddayadda
adding set:versions @rpm5.org has _ALREADY_ introduced
an incompatibility with
E:V-R
in RPM dependencies.
Before we get into all the dreadfulness of additional "rpmlib(…)"
tracking dependencies, and other ugliness needed to deploy
set:versions into the real world (all perfectly doable, just tedious),
I have this observation:
The most expedient way to implement set:versions into
the existing @rpm5.org code base (which is entirely
unrelated to a special case in rpmvercmp), was to
pull the string "set" out of the Epoch: field in the parser.
My RPM related question is this:
Should I generalize Epoch: everywhere to permit strings,
not just digit strings?
If I generalize Epoch: to permit strings in RPM, preserving 1.5y of "legacy
compatibility"
in Alt sisyphus Simply Doesn't Matter (at least to me: I fully understand why
"legacy compatibility" matters to you in Alt).
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
