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

Re: Latest qt4 backports break bpo qtcreator and wireshark



w

On Mon, 18 Jul 2016, Lisandro Damián Nicanor Pérez Meyer wrote:

> On lunes, 18 de julio de 2016 2:19:04 P. M. ART Alexander Wirt wrote:
> > On Mon, 18 Jul 2016, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > On domingo, 17 de julio de 2016 11:13:24 A. M. ART Lisandro Damián Nicanor
> > > Pérez Meyer wrote:
> > > [snip]
> > > 
> > > > I acknowledge that there are a hadful of packages that use Qt5's private
> > > > headers on jessie and that those need a rebuit, I was planning to do
> > > > that
> > > > once the full stack is there.
> > > 
> > > [snip]
> > > 
> > > > Now it seems backports are not ready for uploading bigger stacks like
> > > > this,
> > > > which if it's really the case I can understand it. If so, please do
> > > > *not*
> > > > heasiate and remove harfbuzz, qtchooser, qt4-x11, qt*-opensource-src and
> > > > reject qtcreator ans qbs from NEW.
> > > 
> > > While I wait for, at very least, an aswer to the above from a BPO FTP
> > > master I'll add another technical question, which I would like answered
> > > also by a BPO ftp master.
> > > 
> > > From a technical point of view rebuilding a stable package against a
> > > version in bpo is feasible, but I don't know if it's possible due to
> > > policy/man power to handle them/another issue.
> > > 
> > > As an example, suposse we have
> > > 
> > >   foo_<jessie_version>
> > > 
> > > in jessie. If it somehow required a rebuilt against a package in backports
> > > someone could easily prepare a backports-like upload with version
> > > 
> > >   foo_<jessie_version>+bpo8+1 (note the + instead of the ~)
> > 
> > what is the somehow? That case should never happen. And we don't support it
> > either. Source of backports is only testing (except for security uploads).
> 
> Packages that build against Qt5's private headers or that (like calibre) embed 
> private headers and make apt think they need to get rebuilt in order to be 
> coinstalable.
> 
> If this is the case and it's not acceptable then Qt5 should not belong to bpo, 
> as there are a handfull of packages that fall into this category. The list of 
> packages to be removed was present in my previous mail.
Indeed that is not acceptable and a perfect example for: speak with us in
advance. 

Never break stable.

Alex


Reply to: