[Pkg-xen-devel] Plans for buster

[Ian Jackson]

Hans van Kranenburg writes ("Re: Plans for buster"):
> On 08/23/2018 07:12 PM, Ian Jackson wrote:
> >  IDK if this
> >   should have its own deb.  Putting it in the libxenstore one is
> >   probably tolerable.
> 
> Yes, shipping a 4.x specific file in libxenstore3.0 (which happens now)
> is not right. But, if the library ABI is independent from the 4.x
> versions, then it can be done.
> 
> When starting to add more things which are not libxenstore3.0 to the
> libxenstore3.0 package, shouldn't we find a different name for that
> binary package that covers the content better?

Mmm, quite possibly.  libxenbasic mabye ?

There's an awkwardness that its version will have to change when the
soname of *ether* xenstore *or* toolcore change.

> >  Hans, I know you know there's a problem here.
> >   I haven't investigated what happens with that patch reverted, yet.
> 
> This happens:
> https://salsa.debian.org/xen-team/debian-xen/issues/8#note_39872
> 
> I guess that this is because libxenstore3.0 does not depend on libxen-4.x.

You mean at the package level ?  libxenstore ought not to - see above.
I don't understand the message at the shlibs level.  I think it is
probably that libxentoolcore isn't installed.  But it may be due to
the soname being wrong.

> > * The patch to reintroduce xs_restrict should go upstream.  I think
> >   that, upstream, it would be a backport candidate, thus meaning
> >   Debian wouldn't have to carry it.  (And I'm a tools maintainer and a
> >   stable maintainer upstream, so my initial opinion is fairly
> >   predictive...)
> 
> How do you want to track such TODO items? Because now we have 1) the bts
> and 2) salsa issues and 3) things mentioned somewhere in emails. ;]

Awkward since we still don't have it in experimental.  Maybe we should
use Salsa for short term things and the BTS for things that we expect
will remain open for longer ?

Ian.