New software created for Ubuntu

Raphael Hertzog hertzog at debian.org
Tue May 4 08:02:32 BST 2010


Hi,

On Mon, 03 May 2010, Dmitrijs Ledkovs wrote:
> debhelper, lintian and to some extend dpkg (you would know better ;-))
> are often lagging behind debian during active development in ubuntu
> cycle because we have a few changes that need manual merging with each
> new release in Debian.
> 
> And i find myself switching between the two vendors during my
> packaging activity to make sure my packaging is cross-vendor
> compatible and policy compliant.
> 
> In case of those three packages I would appriciate if all changes were
> merged into respective master branches and the behaviour would default
> to the current dpkg-vendor on the user's machine and do something
> smart when you want different behaviour.

As far as dpkg goes, that's mostly the case. Ubuntu still has a diff but
it gets smaller over time. We hope to be able to sync it directly at some
point.

For debhelper, I can't comment, the diff seems to be relatively small
and for this software I don't think it's a good idea to have much vendor
specific behaviour, at least not anything that changes the result of the
build. Adding hooks to extract stuff is OK. Colin, did you try to get the
few remaining changes merged ? 

Concerning lintian, I think you're right that it would be nice if it could
make use of dpkg-vendor information + the name of the distribution in the
changelog to disable any behaviour that is internal/very specifit to Debian.
Would you please file a bug suggesting this and send back the bug number
so that we can add our comments ? :-)

> For ubuntu originated software I do not understand why we should do
> upstrem release, package as non-native, upload to debian and sync to
> ubuntu, when dpkg, lintian, git-buildpackage, synaptic, aptitude are
> not doing that they simply upload native packages. And note that this
> software is useful outside of debian derivatives eco-family cause we
> still have openSUSE buildservice and folks making debian packages on
> RPM based distors.

Well, I have no problem with you uploading them as native packages
to Debian directly as well. It's just that using native packages is more
difficult when Debian is not the real upstream... we would have to create
new upstream versions to fix debian-specific issues.

> In case of dpkg it would be really cool to merge changes from openSUSE
> buildservice. They have extended what should be a 3.0 (custom) format
> to reuse parts of debian/ dir across different releases. They allow to
> specify a common debian.tar (compressed optionally), reuse rpm
> changelog for debian changelog, and allow per target optional files
> such that you can have debian.control.lenny,
> debian.control.ubuntuhardy, debian.contol (for all the others) and all
> these files are specified in .dsc and at unpack time they files
> specified in dsc and construct package/debian/ using those.

What does this have to do with this discussion ? Ubuntu does not carry
those changes and if you want to see that merged in Debian, you can point
them to our BTS. :)

But your description does not enchant me currently, it looks like
something quite hackish.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/



More information about the ubuntu-devel mailing list