On Saturday, April 06, 2013 11:04:47 AM Dirk Eddelbuettel wrote: > On 6 April 2013 at 17:26, Andreas Tille wrote: > | In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704805#10 Dirk Eddelbuettel wrote: > | > I am not (yet?) sold: > | > -- there is only one "provider" or r-api-* > | > | I can not parse whether this should be a question or a problem. > > In more words: We only ever have one (1) package providing an R interpreter. > That package is r-base-core. > > Because we only have one package, I do not see why we need an additional > token r-api (or whichever wording we pick). > > Let's keep simple things simple.
The point of the API virtual package is not to support more than one provider.
We use this very successfully with sip4 and dh_sip where there is also only
one provider. The purpose is to support transitions effectively.
> | > -- we actually do have a "greater than" relation
> |
> | This is the current implementation and this is not really helpful.
>
> Please demonstrate an actual fault in its design or implementation.
The problem is the lack of a less than relation. Packages built with the old
API don't have any dependency information that would prevent them from trying
to work with the new r-base-core and that won't work. There are only two ways
within the Debian package system to manage this:
1. Modify the expansion of R:Depends to also include a r-base-core (<< 4.0)
relationship. You'd end up with r-base-core (>= 3.0), r-base-core (<< 4.0).
2. Have r-base-core provide a virtual package that gets included in the
expansion of R:Depends. Then you'd end up with r-base-core ((>= 3.0), r-base-
api-3.0.
Either of those approaches ~solves the transitional case of R packages trying
to run with the wrong r-base-core.
>
> We all have our priorities. To me, quite frankly a bigger issue is that some
> debian-{med,science} packages appear to get stale and are not being updated
> for years.
>
> | > -- the version numbers already solve this
> |
> | No, they do not. An API level is something else than a version number.
>
> Version are a (sufficient) superset.
>
> Don't get wrong: I very much welcome your suggestions and involvement.
> ${R:Depends} was a very good idea which eventually won even me over ;-)
>
> But on this, I am not buying the hype yet. Perl has 'api' virtual packages
> because Debian *has* multiple concurrent interpreters. If we are going to
> have a discussion then it should be about redesigning R installations on
> Debian to permit concurrent R-release and R-devel packages. Which may
> require r-api-$N packages -- concurrently.
>
> The current scheme, with its "few" packages, is fine. If I may, I'd simply
> suggest more frequent update of the CRAN packages. I update mine typically
> within a day to a week after they appear.
The idea of using an API virtual package is not tied to concurrent
installation. As I mentioned above, we use this approach with sip4 where that
is not an issue. With sip4, the condition where multiple virtual packages can
come into play is if the API is compatibly extended. The current python-sip
in experimental provides Provides: sip-api-8.0, sip-api-8.1. In this way,
newer packages can depend on the newer features while older packages that were
built before sip-api-8.1 was introduced do not need to be rebuilt.
The current system solves the problem of a newer r-base-core being run with
older R packages, but not the reverse problem of older R packages trying to
run with an incompatible newer r-base-core. I think you're approach of "let's
just update everything really fast" is more of a papering over of the problem
than an actual solution.
If you look at dh_sip shipped in the sip4 source there's a working perl
implementation of the virtual API package approach that would work with R
packages with some simple search/replace operations.
I think the viritual API package approach is better than generating a maximum
depends because (as I showed above) it allows for handling compatible API
extensions and, unlike the maximum version constrain, doesn't require you to
look into the future to know at what version the incompatibility will hit.
Scott K
signature.asc
Description: This is a digitally signed message part.
