On Apr 10, 2011, at 10:01 AM, Per Øyvind Karlsen wrote: > 2011/4/10 Per Ųyvind Karlsen <pkarl...@rpm5.org>: >> RPM Package Manager, CVS Repository >> http://rpm5.org/cvs/ >> ____________________________________________________________________________ >> >> Server: rpm5.org Name: Per Ųyvind Karlsen >> Root: /v/rpm/cvs Email: pkarl...@rpm5.org >> Module: rpm Date: 10-Apr-2011 15:50:29 >> Branch: HEAD Handle: 2011041013502801 >> >> Added files: >> rpm/scripts check-multiarch-files mkmultiarch >> multiarch-dispatch multiarch-dispatch.h >> multiarch-platform >> Modified files: >> rpm CHANGES >> rpm/macros macros.rpmbuild.in >> rpm/scripts Makefile.am >> >> Log: >> merge multiarch-utils from mandriva. > *phew* > > With that, I'm aaalmost done merging, the only remaining script > is the perl dependency extractor, which I want to rewrite a and > improve a bit as well... I hate perl... >
Careful here: every non-trivial change I've seen to perl(...) *RE's
ends up breaking something else.
You MUST run full distro regression tests to change perl(...)
dependencies or there will be endless "RPM sux" complaints.
There is rpmdeps --perl that was written to make the regression
test as painless as possible. 5+ years later, noone but me has ever
used afaik. But *please* verify regressions against a full distro
install (this can easily be fit under buildbot "continuous integration"
too) before muck-a-bout with the existing extraction.
Note also that the perl find requires/provides is written as separate
scripts. The morern (heh 8+ year old) invocation template is
-P,--provides
-R,--requires
and have *both* (and -C,--conflicts, -O--obsoletes for generality that
noone has ever attempted afaik) extractions resident in the same script.
Since every bleeping automated helper is implemented/delivered in its own
peculier
language and noone (except Ville) is ever really bothering with maintaining
the patterns taht are in use, having a single script, using -P/-R as above
is MUSTHAVE. I can't possibly support/maintain scripts in every possible
language
within RPM distributed code UNLESS its a single script. And even then I don't
think every scripts from possible interpreter language belong in rpmbuild
whatsoever.
There's most definitely a combinatorial failure distributing "fixes", and it
takes *years* to distribute/deploy even trivial 1-line changes if the scripts
are distributed with RPM. Enuf already ...
> I think the perl dependency extractor will be the only mandriva
> specific script left now, I think I'll just consider myself satisified
> with using it as is for now, then perhaps rewrite later..
>
Cool. You might want to send a list with desired priorities.
Why you are mucking about with perldeps rewrites after Mandriva
beta2 is no priority that I understand. Usually rp[mbuild is locked
into so so so much concrete by "beta2" that any change is impossible.
> At least now it's out there! :)
>
> I'll try merge the remaining macros from rpm-{mandriva,manbo}-setup
> into macros/mandriva or the corresponding macro files where
> appropriate, almooost done putting it to rest now.
>
Please try to do better wit Mandriva peculier dialect macros. Its
silly to check-in, and then have to move.
My criteria SHOULD be obvious:
What is distributed by @rpm5.org MUST be vendor-neutral.
That is the policy since day -7 here @rpm5.org.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
