New software created for Ubuntu

Dmitrijs Ledkovs dmitrij.ledkov at ubuntu.com
Mon May 3 17:55:29 BST 2010


On 3 May 2010 16:10, Raphael Hertzog <hertzog at debian.org> wrote:
> On Mon, 03 May 2010, Barry Warsaw wrote:
>> Apologies for parachuting in and hijacking this thread, but I don't think it's
>> a matter of people not wanting their work to show up in Debian and Ubuntu.  I
>> think it's a matter of two different enough development policies and
>> infrastructures.  It's difficult to grasp the details of how to deploy
>> packages for each distribution, let alone the best way to sync packages
>> between them.  Even if you do get it, it's time consuming to support both.
>> The question is: what can be done to make life easier for those who /want/ to
>> do the right thing?
>
> The real question is: what was difficult for the people who tried it?
>
> I'll gladly try to make any supplementary improvement in the
> infrastructure on the Debian side if needed but I don't think we can speak
> in the void without basing the discussion on concrete experience.
>

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.

E.g. for lintian: lintian-debian lintian-ubuntu symlinks or flags
--debian --ubuntu or something cunning like autodetect which vendor
the package is targetting and envoke / suppress $vendor compliance
checks (e.g. nmu, binnmu, Original-maintainer etc)

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.

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.

openSUSE buildservice is the only one I know that builds for Debian
and publishes apt-getable archives (binary only due to possible custom
source packages). But it doesn't surrport testing or sid which would
be really cool to have.

http://en.opensuse.org/Build_Service/Deb_builds
http://lists.opensuse.org/opensuse-buildservice/2007-03/msg00067.html

For software-centre & ubuntu-one dependencies should be packaged as
non-native. The apps themself I would argue should be packaged as
native - you want to share debian packaging & rpm distors don't care
about debian/ and might use it as a reference when doin their
packaging (I think openSUSE has auto-deb2rmp builds running btw)

As for branding software-centre should be debranded for debian and
inlude volatile, contrib, non-free & backports channels.

With ubuntu-one it should not be debranded because as far as I
understand it is a separate canonical trademark & service which is not
vendor specific like synaptic. E.g. it should be ubuntu-one music
store, ubuntu-one sync service across all operating systems that
package it.

Ubuntu themes you would wnat to use debian swirl but the rests needs
to be there. (as far as I remember human theme still has high popcon
in debian)

> The most annoying part IMO is the need to find a sponsor on the Debian side if
> you're not Debian Maintainer or Debian Developer. Maybe there should be a
> team on the ubuntu side composed of DD also involved in Ubuntu that would
> be more inclined to sponsor those in the generic case.
>

I maintain a few packages in debian as part of ~pkgcrosswire team. I
believe we are lucky we have:

1) 2-3 ubuntu contributors doing packaging
2) 4-5 upstream developers who keep us on our toes
3) 2 debian developers who sponsor uploads

Uploads / syncs to ubuntu were done via Ubuntu sponsors team.

An active ~debian-mentors team on launchpad will help a lot with
finding DD's who are friendly to sponsor ubuntu-originated software
(e.g. people who are both Ubuntu & Debian Developers) cause I was
stuck a few times when wanted to upload something not related to
~pkgcrosswire and debian-mentors lists was a bit intimidating.

> 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/
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>



More information about the ubuntu-devel mailing list