pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
The following reply was made to PR pkg/45345; it has been noted by GNATS.
From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Mon, 5 Dec 2011 16:43:12 +0000
On Tue, Nov 29, 2011 at 06:50:04AM +0000, OBATA Akio wrote:
> > >> expat hasn't been updated since long before netbsd-5 shipped.
> > >
> > > It's just a lucky.
> > > (for netbsd-4, no releases including fixes for CVE-2009-3560 and
CVE-2009-3720 yet)
> > I didn't realize expat was even in netbsd-4's X11... but apparently it
> > is.
> > this should be fixed. let's open a fresh PR for it.
>
> No need to file new PR, just NetBSD-4.0.2 (or 4.1) release is required.
oh. well, that's not going to happen, as far as I know.
> > >>> How do you think about databases/py-sqlite3? it is same situation.
> > >>> ${PYLIB}/sqlite3/* exists in base python package, but lack of
_sqlite3.so.
> > >> I think that's wrong too.
> > >
> > > Then, this issue should be send to upstream first.
> > > I think that it is the default behavior of python distribution.
> > I don't think so. Both py-sqlite3 and py-expat are built out of the
> > main python distfile. And look at the first hunk of
> > lang/python26/patches/patch-am, which suppresses the standard build of
> > those and other builtin modules.
>
> It's just exactly disabling to built those modules, or builtin
> sqlite3 libraries may be detected (It is not expected behavior).
Right. But the reason it does that is that we build the sqlite
material separately in the py-sqlite3 package.
That is, that separation is something we did, not part of the default
behavior of Python. There would be no point contacting upstream.
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index