[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#868558: nmu: multiple r-* packages



Dirk Eddelbuettel:
> 
> On 10 September 2017 at 16:15, Niels Thykier wrote:
> [...]> |
> Next April they will have r-api-4.

Ok.  If the r-api-4 bump in April works like I think it does, then that
will also resolve this problem as a side-effect.  So in worst case, we
can do a regular transition of r-base in April and I will be happy to
remove these block hints at that point (assuming the situation has not
been resolved prior to this).

> *This case* did not warrant puzting with
> r-api-* and you will have to take my word for it.
> 


This part seems to be the entire basis of our disagreement.  I admit
that I cannot grant you a leeway here as it is one of the most basic
things in our job description - keep testing working smoothly.


From our perspective, if it breaks reverse dependencies that has not
been rebuild, then it *does* warrant bumping $SOMETHING.  Usually
regular package name, sometimes a virtual -abi or -api package.  This is
to ensure britney migrate things in the correct order and ensures that
users cannot end up with two packages that do not work together.
  This approach does end up requiring more packages to be rebuilt than
what is theoretically necessary.  But that is generally a non-issue
(provided the reverse dependencies are "arch:any" packages so they can
be binNMUed).

If you need the "r-api-*" package to stay in sync with an upstream API
number or it is for arch:all packages, then please consider introducing
a separate package (e.g. r-abi) that can be bumped independently and
have .C (etc.) using code depend on that as well.  Unfortunately, this
newly created package cannot be used in this case (it has to exists
prior to the breakage), so it is only suitable for future problems.

> | > Dear debian-release:  Please remove this block.
> | > 
> | I respectfully decline.
> 
> That's truly and madly saddening. So I will just code around you and direct
> users to a different repo.  We have been doing that via an informal backports
> repo available at all CRAN mirrors anyway.
> 

Ok.  Again, I am truly sorry you feel that way.  But that is your choice
and you are welcome to do that.

> It's too bad, but we all have our standards to live by.
> 
> Apparently I am now rogue as far as the release teams goes. Life goes on.
> 
> Dirk
> 

You are welcome to define yourself as "rogue", but please keep in mind
that it is a "self-inflicted" label.  We do not label you any different
than any other Debian contributor.  Likewise, our requirements to you
are the same as to all other Debian contributors.

 * If you change your mind, we will be happy to assist you with the
   transition (provided it fits in the freeze schedule).

 * We are also happy to work with delegates on your behalf if you prefer
   that.  Our requirements will be the same to all contributors so they
   will receive the same instructions.

 * We can wait until the r-api-4 bump in April if you prefer that.

Thanks,
~Niels


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: