Bug#474947: the state of Bug#474947
>From: Eugene V. Lyubimkin <jackyf.devel@gmail.com>
> Elliott Mitchell wrote:
> > I have made no such claims. I am merely stating that this is a serious
> > bug. Severe enough to seriously consider delaying the release. This is
> > what the release team gets to decide, which is worse (neither option is
> > good)?
> Yes. So, If you claim this have to be fixed before Lenny, go ahead and ask Debian release
> team what they think about changes in internals of apt and additional month(s) of testing.
>
I thought that was the point of copy the messages to their list was.
> It might be found that fixing it isn't anywhere near as bad
> > as you thought. Even though it changes the API/ABI, if no one has ever
> > touched that field, the impact on other packages will be zero.
> Yes, it will change ABI and API. This will cause recompiling packages that rely on apt
> against new apt, and would cause breakage of some apt-dependent tools (such as aptitude,
> perl and python bindings). Another big pain for other developers.
Adding a level of indirection isn't a very big change. Yes, it has
effects all over the place, but 95% of those are pretty simple (can
mostly be done with `sed`). The difficult part is change the allocator,
which I presume is the portion you did?
> > Perhaps
> > the release team will decide it is worth delaying the release, in which
> > case a head start in testing will be of great value. Perhaps some other
> > issue will force a delay of the release, in which case the extra time
> > might allow sufficient testing.
> Perhaps. And perhaps not.
>
> My conclusion: please not force fixing this bug before Lenny until release team agree to
> change internals of apt at this stage.
My point with the above is to keep working on it. Even if slight, there
is a very small chance it might be possible to complete in time.
As for combining bug reports, #474947 is distinct from the #380509,
#413024, #429171, #431410 and #451526. None of those includes a
segmentation violation. #474947 might get fixed simply because fixing
the little core piece will prevent it from being tickled or the rewrite
might just squash it; but I still think it is distinct.
I also think #429173 should be separate from that grouping. Again, this
one might never show up, if not for the MMap issue; but this issue is
that locks are left behind on error, not the MMap issue.
On the flip side, #474947 might be the same as #443564. The MMap issue
shows up, followed by a segmentation violation. Similar fixes work, but
that is due to aggrevation by the MMap issue, without that bug these
might be clearly distinct.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | EHeM@gremlin.m5p.com PGP F6B23DE0 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0
Reply to: