On Mar 15, 2012, at 12:43 PM, Allen S. Rout wrote:
>
> Thanks for your thoughtful reply!
>
>
> On 03/15/2012 11:50 AM, Jeffrey Johnson wrote:
>>
>> You can find me on
>> <[email protected]>
>> if you wish to continue the discussion. I am "moderated" (aka "censored"
>> on<[email protected]> for (my guess) "forking" political reasons.
>
> Heh. Sounds like a story. :) I infer that RPM 4.9 is not tending
> toward rpm5?
>
Not bloody likely. *shrug* I am _STILL_ the 2nd largest committer
@rpm.org and I haven't even touched their code for 7 years.
>
>> (aside)
>> Does R have a CRAN like CPAN/CTAN/rubygems/pythoneggs/etc?
>
> Yes, exactly.
>
>> If so it might be overall a better implementation to add support for
>> CRAN -> RPM (and register the changes in an rpmdb) than attempting
>> Yet Another complex mapping between huge namespaces.
>
> You've got my antennae quivering. Can you point me to other places
> where this is done, and/or exposition about how such a structure Ought
> To Work?
>
I'm currently working through alternative transports to *.rpm packaging
for various reasons. E.g. TeX which has always been a large awkward
package is now exploded into thousands of sub-packages and the
results aren't all that pleasant. choosing the names is already a chore.
In addition to CTAN, there are ruby gems, which aren't half-bad imho:
its kinda cool when new stuff just magically appears in seconds without
all the drudgery of package management.
What isn't so cool is when rubygems breaks, because then you have
a chore cleaning up busted stuff all over the place. Whether you like RPM
or not, its unquestionably really good at removing what was installed,
so you get (essentially)
Free do-overs.
The missing piece in the above is no means to register CTAN/rubygems
(or eggs or locales or CPAN or CRAN or …) in an rpmdb with the
contents that were just pulled in.
It really isn't all that hard to create a *.rpm package header and do the
registration from within RPM. From outside of RPM, its considerably
more difficult because RPM hasn't a maintainable API: there's always
something Newer! Better! Bestest! that has to be deployed in distros
(like multilib, or selinux, or …) and RPM libraries really weren't designed
for their current usages.
So -- if you wish -- I could attempt to use CRAN as a proof-of-concept
model for the class of alternative transports like CPAN/CTAN/whatever.
That would actually be beneficial: R has a bit more discipline and
predictability
than the other choices. E.g. CPAN is just a sewer of anarchism, and CTAN
reinvents itself every few years with different maintainers and content.
But if you'ld like me to try doing CRAN registration into an rpmdb, I'm
not at all averse. I'd need some markup format like XML/YAML/JSON/INI
to parse to get the elements that were installed to create a header that
could then be registered in a rpmdb.
The net positive effect is this:
You wouldn't have to write *.spec files for all of CRAN
The neutral effect is that RPM <-> CRAN dependency mapping would
be inside of RPM. This is "neutral" (for you) because it will be harder
to change the mapping: RPM changes very very slowly. I'd actually
prefer the mapping in RPM so that there's some sort of de facto reference
standard. What tends to happen is that all of CPAN/CTAN/etc tend to
reinvent themselves every few years, totally blowing away all previous
implementations (which are not always updated/maintained).
There are perhaps some negative effects too. But I'm not at
all averse to trying to device some means that RPM can register
a CRAN "package" as if it had been built by rpmbuild etc.
>
>
>> OK. You would need to supply R's semantic for [...] more precisely
>> for me to understand a mapping into RPM dependencies.
>
> I can expound on this in detail if you like, but the succinct
> statement is that Depends and Imports refer to things RPM would call
> Depends; those are packages which provide symbols or function which
> 'I' (speaking as the package) need. The rest of them are interesting
> for someone wanting to see all the flashy demos, but not appropriate
> install dependencies.
>
Better than words are examples that I can roll into test cases.
>
>> IOW, you only need to worry about LOOP's for executables that will
>> be used while installing R packages.
>
> I also need to calculate them correctly as I'm building the tree, else
> I won't be able to execute the checks.
>
I can likely help some with topological sort and LOOP removal in a dependency
graph once I get a feel for what Enhances: is doing to an R dependency graph.
>
>> So 'CHECK' is R's dependency checker?
>
> OK, maximum pedantry here: 'CHECK [package name]' runs a collection of
> code associated with a package, called the packages 'Vigniettes'.
> These exibit some testsuite-nature, and some documentation nature, and
> some show-off nature; they are some measure the PR and advertising for
> the package. "See what cool things you can do with my package!??!".
>
OK. I can start to understand how the sub-modes of CHECK can be mapped
into *.rpm. E.g. there's a
%verifyscript
section that might be a place for "… testsuite-nature …" items that is
run by rpm --verify (and can be disabled with --noverifyscript).
> A successful run of R CHECK is a precondition of a package version
> being accepted into CRAN; it's the recognized convention for checking
> to see if the package is working. But the show-off nature tends to
> maximize interpackage links.
>
OK
>
>> Dunno whether adding 'CHECK' to RPM is wise but its certainly
>> feasible.
>
> I have been viewing CHECK as something we (as repo maintainers) would
> want to do for a package before releasing it. We'd perhaps do it as
> part of the RPM build process, but I wasn't figuring that checks would
> be performed at rpm install time.
>
Well if CRAN is used, you are assuming that the repository has
a property that maps onto the install system without being re-verified.
RPM itself depends a lot on a similar build -> install implicit mapping
of certain properties. In most cases that isn't too bad an assumption.
But there is no substitute for actually testing what is actually installed,
in this context that would be attempting to run CHECK (or some subset)
functionality on the install machine (e.g. consider the %verifyscript I just
mentioned).
Again I'm just talking, I haven't a clue what CHECK does: I would need
assistance from
you about what might make sense and what is utterly daft.
>
>> Ah: so you are attempting an incremental "opt-in" approach turning
>> on dependencies until the problem is well understood. That is
>> certainly a sound approach.
>
> I'm glad it looks sane from outside my skull.
>
>
>>
>> There's lots of solutions, ultimately its up to you.
>
>
> heh. Well, options are good; I must admit I was hoping that the RPM
> community had some applicable dogma on the Right Way to approach this
> topic. :)
>
Short answer:
I'd be happy to help get R packaged up smoothly.
(aside)
IIRC, I added R *.rpm to packaging to Red Hat powertools last century ;-)
So do you thing R can generate enough markup that I could construct
a package header that can be registered in an rpmdb?
Try this command on some R *.rpm to see what is in a header
$ rpm -ql --xml whatever*.rpm
(RPM @rpm5.org also has --yaml and --json markups, so I can
likely parse whatever is easiest for R to generate: what I don't know is
how rich your CRAN package metadata actually is(.
73 de Jeff
>
> My current inclination is to use some irritating release-specifier
> internal code, so long as I can make the unchecked package collate
> _before_ the live one.
>
> So for the R package "RColorBrewer", version 3.6.9 I want to end up
> with a distributed package
>
> R-RcolorBrewer-3.6.9.el6
>
> I'll have to research release collation, to see if I can do something like
>
> R-RColorBrewer-3.6.9-pre.el6
>
> and then later upgrade it to
>
> R-RColorBrewer-3.6.9.el6
>
> Worse come to worst, I could make the "pre" package release -1, and
> the intended-for-consumption release -2. That feels dirty to me, but
> maybe I'm being too fastidious.
>
>
>
> - Allen S. Rout
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List [email protected]
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
