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

Re: Bug#673586: FTBFS if Python 3.2 is installed in chroot



On Wed, May 15, 2013 at 11:31:03PM +0200, Didier 'OdyX' Raboud wrote:

> > However, seeing that the package is in collab-maint, I'm going to go ahead
> > and pick off some of the lower-hanging fruit right now by pushing the fixes
> > to git.

> I feel compelled to point out here that this is not how I understand collab-
> maint is supposed to work. That said, in that case, despite preferring commit 
> messages not including debian/changelog messages in favour of git-dch, I'm 
> happy with your commits that I had already committed (but not pushed) :)

Whoops, sorry for the misunderstanding.  I guess there isn't a consistent
view of what "collab-maint" means; I always understood it as meaning that
any developer could always commit fixes there - though of course only the
maintainer should upload unless the package is also covered by the "Low
Threshold NMU" rules.

Would it be ok if I pushed any future changes to a separate branch in git
for your consideration?  Or do you prefer that I send all patches by mail?

> I have uploaded your changes as +Debian11 with some changes of mine.

Nice, thanks!

BTW, I just noticed that the source package for +Debian11 contains the
source tarball for +Debian10... oops ;)

> > The remaining delta consists of a few pieces:

> >  - The actual switch to python3.  What are your thoughts on this?  It's not
> >    a high priority for the python team in Debian as it is in Ubuntu, but it
> >    should be safe.  The packaging in Ubuntu currently relies on running
> > 2to3 at build time, however; since this is a native package, if we want to
> > switch to python3 (and given that you already have python2.6 as the
> > baseline for modules), we should really make those changes in place in the
> > code.  Do you agree?  Would you like to go ahead and make this change?

> I don't have a very clear vision yet on the impact of such a change on the 
> rest of Debian (d-i and default installation footprint come to mind) as lsb-
> release will pull in python3 in quite a lot of situations. I will therefore 
> branch the code and upload the work-in-progress in that direction to 
> experimental.

Ok.  For the record, d-i is universally python-averse, so it doesn't matter
if it's python2 or python3, lsb-release is definitely not included in d-i.
Also, while python is Priority: standard, both python3 and lsb-release are
Priority: optional.  It should probably be discussed with the wider Debian
Python community what the plans are here for jessie, but I *suspect* it will
be reasonable to flip these two, especially as it appears the only Prio:
standard packages using python are apt-listchanges and reportbug.  Neither
of these are part of the default install in Ubuntu, so unfortunately there's
no python3 porting that's been done on them to date over here; but
python-apt is the only external dependency and there's a python3-apt, so the
remaining porting work should be fairly small.

<snip other delta which needs no discussion>

> > So certainly nothing insurmountable, but it'll take a little time to get
> > things fully in sync.

> The Jessie release cycle could be enough, we'll see.

Yep, seems feasible.

> > Oh, fwiw, I have to say I'm not a fan of the derived_from_ubuntu logic in
> > the Debian package.  I think it's vastly preferable to keep such
> > differences as source package deltas than to have the same source package
> > give different results when built on different derivatives.

> Well; having all changes happen on the same codebase (and VCS) IMHO helps 
> avoiding useful distribution-agnostic changes in derivatives as contributors 
> are compelled to think twice whether the change is agnostic or specific 
> afterall.

I don't think this has the effect you hope for.  Unless the person making
the change in the derivative also has commit access to the Debian VCS, there
will always be a tension between trying to do things "upstream first" and
answering to the demands of the downstream release schedule.

So even getting lsb in sync in Ubuntu is no guarantee that it will stay in
sync.

> > I'm not sure it's worth changing it in this case, but if you were to drop
> > the Ubuntu-specific bits from the Debian package, that would be just fine
> > with me.

> Thanks for making that explicit. As long as they don't come in either your
> or my way, I see no reason either to drop these.

> Looking forward to more collaboration from Ubuntu on src:lsb ! :)

Likewise ;)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: