Re: Are there other derivatives based on Debian Testing?
Hi,
On Thu, 16 Jul 2015, Klaus Knopper wrote:
> > Are there other derivatives affected by such breakages and that would
> > be interested in cooperating to:
> > - try to avoid such breakage in the first place
> > - try to limit the amount of time testing is broken for us
>
> It happens in Knoppix, too, mostly because of invalid, missing or very
> stubborn dependencies (such as network-manager depending on systemd).
> It's resolved here by some manual apt-get magic plus, in rare case,
> forks of packages with changed dependencies. In the latter case, you can
> find the sources at http://debian-knoppix.alioth.debian.org/ .
Those are not really the kind of issues that I'm encountering. What I'm
referring to right now are issues that are breaking jenkins jobs
on our sides:
- test install of our meta-packages
- test build of ISO images
- test install of said ISO images
So a package failing to install is a problem. A package that disappears
from testing and which is in the dependency tree of our meta-packages is
also a problem.
> > We push temporary fixes in our kali-dev repo but it would be better
> > for everybody if such temporary fixes would reach testing itself.
>
> From my experience, it's much less stressful to file an official bug
> report (reportbug) in case of problematic package configurations or
> dependencies in the original debian/testing, but create and maintain
> solutions "private" to a derivative and publish them in parallel, so the
> original package maintainers can have a look on your solution. But still
> I'm looking forward to hear about your personal experience discussing
> desired package changes with the original maintainers & the results. :-)
Well, that's perfectly fine but it's unlikely to "unbreak" testing in a
very short timeframe. Fixing things in unstable is the natural first step and I
do that too. Since I'm also a DD I even do non-maintainer uploads when
it looks like that the maintainer disappeared or when the maintainer
welcomes NMU. I did that recently for "debtags" or "tcpick" for example.
In both cases, I kept an older version of the package on Kali's side until
the fixed package migrated.
The idea is to have someone of us join the release team in order to deal
with our requests:
- either to ensure fixed packages migrate from sid immediately
- or to approve fixed packages that would be uploaded to
testing-proposed-updates
We should define in coordination with the release team what kind of
updates are acceptable in this context given that such updates would skip
the usual "aging" delay.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
Reply to: