Jose' Matos wrote:
On Thursday 08 June 2006 04:37, Marc Schwartz wrote:
It probably raises a PM coordination issue if one has packages
installed from an official FC repo as well as from CTAN directly,
but I suspect this would be a technical hurdle that could be
overcome in time.
This solution seems intriguing, but I suspect there will be a lot
of discussion with the TeX community before some form of distro
agnostic solution is proffered. FC7 might be a reasonable target
relative to timelines...
I see CTAN the same way I see CPAN (perl) or CRAN (R). What we have
been doing till now is to distribute those packages separately. We
have some additional constraints that they don't have, for one we
usually check the license while as far as I know that is not done by
default for the native PM. (I may be wrong here.)
José,
No disagreement. Indeed, being a heavy R user (I'm off to the useR! 2006
meeting in Vienna next week), I would agree in principal.
For R users who install from FE (I install from source tarballs), there
is the main R RPM and the subset of CRAN packages that you and
Tom have kindly provided.
If someone wants to update using R-patched for bug fixes (which I do
frequently) or needs to install a CRAN package that is not in FE, they
go to CRAN and install from source.
The difference here, at least with R, is that the process of
installing and updating CRAN packages can be done entirely within R
using functions (ie. install.packages() and update.packages() ) that
have been specifically created to support this via OS agnostic means
since R runs on *nix, Windows and Mac. Indeed, even the CRAN mirror
selection process can be done using a tcl/tk widget.
You guys don't strip out those functions in the FE R RPMs to force users
to install CRAN packages using YUM/RPM. You can't or you would restrict
the ability of users to do what they need to do, or make the FE R RPMs
of minimal value and ultimately, a waste of your time.
On FC, this duality can clearly result in the potential for version
control conflicts if one is installing using FE RPMs and native CRAN
packages. Something that is required given the reality that you guys
can't be expected to offer and manage the hundreds of packages on CRAN
as RPMs for FE.
Not even the Debian folks, who offer a large number of CRAN packages as
.debs, provide all of them and they have had extensive discussions on
trying to handle the version control conflicts.
In addition, CRAN packages, like CTAN packages, are not under the
release control of the core upstream developers, since they are
contributed by users. CRAN packages do have to go through a rigorous
testing process to meet certain criteria in terms of structure and
content, but can otherwise be updated at will by the package maintainer.
Thus, updated CRAN packages, whether for bug fixes or functional
updates, can appear at any time, with no formal release schedule.
I suppose that MPM might be a CTAN parallel to the built-in R
functionality in a fashion and perhaps is something that ends up in FE
at some point. This is why, pending further discussion on TeXLive, I see
it (or something similar) as having value, given that attempting to
manage the number of CTAN packages is a magnitude more difficult than
CRAN packages. MPM, would, from an end user standpoint, make the
updating and installation of TeX packages easier than the current manual
process.
I don't think that it will be reasonable to expect Jindrich to be able
to singularly manage the TeX package updating process. Especially if, as
has been the case with teTeX, the upstream offering is not updated with
some level of frequency, since TE himself was limited in resources,
resulting in his recent decision. Other than early bug fixes, there were
no incremental package updates to teTeX by TE.
Jindrich has kindly updated some of the packages recently (ie. caption)
for FC4 and FC5, which were terribly outdated (~2 years) relative to the
current versions on CTAN. However, unless the new upstream process
institutes a more frequent package updating mechanism (not just bug fix
releases), future FC/FE offerings will face the same challenges.
At the same time, there are frequently used CTAN packages that have not
been in teTeX (ie. ctable) and need to be installed locally. It's fine
to file RFE's in Bugzilla (which I have done), however again, I'm not
sure that it is reasonable to expect Jindrich to be able to respond when
the upstream package management process is problematic. A tool like MPM
(or a similar offering from the TeXLive folks) would make this process
much easier.
Also, as with CTAN, there is a need to check CRAN licenses, as not all
CRAN packages are GPL (though this is a rarity). The built-in R
functions do not check this and so it is up to the user to check to see
if there are any restrictions on the use of CRAN packages. FE package
maintainers would of course need to be diligent on these issues as you note.
The discussion on the TexLive list seems entirely reasonable and
parallels the R offering, which has a Base (Core), Recommended and CRAN
(Extra) model. The former two being included in the main R distribution
together, since the Recommended packages are by the R Core developers
themselves and do offer common statistical methods (ie. survival
analyses, classification and regression trees, etc.) that are logical to
have as a foundational offering.
I suspect that this combined approach may not be replicated with
TeXLive, unless the outcome of the TeXLive discussions is a single
offering similar in scope to the content of teTeX as a default with a
separate second tier of Extras. It does sound like there are those who
are leaning to a three tier approach, which is always subject to change
of course.
Then there is the tension from the developers of that tools saying us
to abandon our PM and use theirs instead. I am not convinced that is
the best solution. With all its faults I still prefer a generic
solution like rpm with a strong policy over it that to have to
download the same packages all over again like those systems propose.
Again, no disagreement in principle. I suspect that we will need to be
patient and get a sense for the result of the upstream discussion and
the resultant offering, including any upstream PM tools that are agreed
upon. We can then have the requisite discussion as to how that outcome
fits for FC/FE.
Best regards,
Marc Schwartz
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list