New software created for Ubuntu

Tue May 4 09:21:36 BST 2010

On 4 May 2010 08:02, Raphael Hertzog <hertzog at debian.org> wrote:
> 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.
>

Would it be quicker if the ubuntu diff lived in the dpkg git repo as a
branch and you would try to merge it and if it's non-trivial merge or
breaks behaviour ping ubuntu folks?

> 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 ?
>

It's upstart maintainer scripts for dh_installinit and as far as I see
ubuntu specific udev conf files migration. But debhelper does gain
features very quickly so I want to have newer debhelper as quickly as
possible =)

> 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 ? :-)
>

Will do. Later tonight.

>> 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.
>

The issues with native package versions in general are NMU and binNMU.

23 - debian release
23ubuntu1 - ubuntu changes to debian 23
23.1 - debian gets nmu
23ubuntu1+really23.1ubuntu1 - ubuntu changes to 23.1

Similar goes with binNMU

Doing debian specific fixes for ubuntu native packages would be even more ugly.

There were proposals to do 23.0ubuntu1 to change debian native
packages but I don't think that caught on.

It would be awesome to scrap native package versions all together and
create source packages "native-like" if explicitly asked to do so via
debian/source/format or command-line options. And shut up lintian
about this =)

I've seen way to many upstreams trying to do NN-1 packaging of their
project for their personal consuption and they keep on not getting how
they can get .orig. tarball when they are simply building a package
out of their VCS.

And since now dpkg has no problem throwing away upstream debian/
packaging does it makes sence to abolish native packages as a whole?

>> 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. :)
>

Well they are too busy filtering debian main & not importing ubuntu
universe because they are not happy with codecs (ffmpeg was cited
once) in the archive. [1] openSUSE BuildService is very nice and it
would be cool to have it running for sid, testing, ubuntu+1. I've
argued by case [2] maybe they will reply.....

Anywho this is off-the topic.

[1] http://lists.opensuse.org/opensuse-buildservice/2010-04/msg00251.html
[2] http://lists.opensuse.org/opensuse-buildservice/2010-05/msg00024.html

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

It is quite hackish & it doesn't even attempted building native
packages at all because they beleve debian.diff.gz is a *must* to
build debian package.

> 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/
>