pre-spec discussion: modified-source backports

On 11/23/05, John Dong <jdong at ubuntu.com> wrote:
> > Now for the backporting policy: build-dep changes should be okay, but
> > I'm not that confident with 'unpatching upstream-specific changes'.
> > Whats that? we are shipping software, developed by their upstreams.
>
> I meant changes in Dapper that were specific in Dapper, like how launchpad
> integration got added to Breezy and caused most main packages to be
> unbackportable. Most of those are in the debian/patches directory and could
> be easily and cleanly removed without affecting the package much.

Only if the maintainer did choose using a 'patch'-system like dpatch
or dbs. Thats no requisite, because all patches go to the .diff.gz
anyway. What do you do in this case?

> > I have another question to be cleared in advance: Are packages in
> > -backports being build against the stable release or against the
> > -backports repository as well? You see the difference?
>
>
> Yes, I see the difference. By default, built against stable release because
> I want people to be able to pick backports independently from the rest of
> the distribution. But when pulling new packages back, I may introduce new
> library packages that aren't in Breezy at all (like libtorrent/rtorrent
> addition in Dapper), in which case it's only possible to compile against
> breezy-backports's libtorrent.

So you'd like to choose? Interesting. You should really talk to the
launchpad artists then, because this backporting functionality needs
to be implemented there anyway.

How is it handeled atm? Are backports build in a breezy-backports 
chroot or in a 'plain' breezy chroot?

> I'd like to have this too, that'd be a cool feature. :). Even cooler would
> be a frontend/GUI for Dapper to choose backports :)

Thats easy. The amount of work for the archive software is the
problem, not the small gui, which could be perhaps an extension to
synaptic or even smart.

--
regards,
    Reinhard