Hi Thomas, No, I don't believe anything other than Xapi depended upon blktap, though it could theoretically be useful to anyone who wants VHD-backed disks. I no longer work for Citrix, though, so I'm not the best person to comment on this.
Mike On Sat, Feb 8, 2014 at 11:18 PM, Thomas Goirand <z...@debian.org> wrote: > Package: ftp.debian.org > Severity: normal > > > Hi, > > Writting this message saddens me, but no choice... > > Because upstream authors (eg: Citrix) have explained that they cannot > maintain the current version of XenAPI, or upgrade it to a newer version, > we have no choice but to remove completely XenAPI from both Unstable and > Testing. Quoting Euan Harris from Citrix (it's not needed for the FTP > masters to read, however it's useful to have this in a public bug for > future reference): > > > the next 5 years. Unfortunately the changes we had to make to the XCP > > packages to make them build on Debian made them effectively a fork of the > > XAPI Project as used in XenServer at that time, and it is increasingly > > difficult to backport changes from 'upstream' XAPI Project to XCP. > > > > I previously mentioned a project called 'xenserver-core' > > (https://github.com/xenserver/xenserver-core) which aimed to improve and > > standardize the build and packaging process for XenServer's components. > > As part of project we cleaned up many of the CentOS/RedHat-specific > > dependencies in the packages, and we are now pushing those changes back > > upstream to the main repositories including those of the XAPI Project > > (https://github.com/xapi-project). > > > > xenserver-core also had build scripts which let us build the packages > > on RedHat- and Debian-derived distributions. We plan to integrate this > > build code into our main build system, so we hope that we will not see a > > repeat of the divergence that occurred with the XCP packages as we will > > be building (internally) on Debian on a regular basis. We hope that > > this will mean that our trunk branch and future releases will be much > > easier for packagers to build in future than it has been in the past. > > > > In summary, the current XCP packages are not in a good enough condition > > to go into Ubuntu Trusty and the trunk XAPI Project is not yet at a point > > where a release can be made. Typically we do this when XenServer is > > released and the XAPI code has had significant testing and stabilization > > through XenServer's QA process. > > > > Regrettably, we agree that there is no alternative now but for the > > XCP packages to drop out of the Ubuntu Trusty. We would like to get > > packages in Debian testing again in time for the next release, but those > > should be based on releases from XAPI Project trunk rather than the XCP > > branches, which should be considered dead. We don't have the resources > or > > expertise to build the packages ourselves, but we are keen to work with > > you (or other Debian maintainers) to fix any Debian-specific problems > > which make our code difficult to package. As I've explained above, we > > are putting a lot of effort into making the XAPI Project code portable > > and less distribution specific, so we would hope that packaging it for > > Debian will now be much easier than it used to be. > > To give a shorter submary: XCP in it's current Debian form is dead, and > may be replaced by xenserver-core when upstream consider it in good enough > shape. It is my intention to work on that when it is available. But in > the mean while, I hereby request the removal of the below packages from > both Sid and Testing: > > - guest-templates > - xcp-eliloader > - xcp-storage-managers > - xcp-vncterm > - xen-api > - xen-api-libs > > I am currently unsure if we should keep: > - blktap > - blktap-dkms > > I would appreciate comments from knowledgeable people like one of the > 2 Ian (eg: Campbell, Jackson), or Mike about this. I currently believe > that blktap isn't needed anymore outside of XCP, so unless they oppose > to it, we can delete these packages (if we later need them, I can anyway > upload again using what we have stored in the Git of Alioth). > > Thanks, > > Thomas Goirand (zigo) >
