FAQ

This page contains frequently asked questions regarding Packaging and Ubuntu Development, for FAQ MOTU specific please see MOTU/FAQ.

Starting Points

Be sure to check out these pages as well:

I want to maintain a package

Here's what it means if a package has your name and mail address in the Maintainer: field in debian/control:

  • You will take care of the package's bugs. It makes sense if you are bug contact for that package in Launchpad.
  • You will liaise with upstream.
    • You track what's going on upstream.
    • You will try to build a good communication to the upstream developers.
  • You will find out how to fix bugs appropriately. Uploading new upstream versions is just not enough. (Think of fixes in stable releases.)

How do I get my changed package into Universe/Multiverse?

Via the SponsorshipProcess

NOTE : If it's important enough to be shipped in the stable distro, read StableReleaseUpdates.

Can <package> be upgraded?

If you want to file a request to get <package> upgraded to a new version, please file a bug in Launchpad an tag it as upgrade.

If we're currently in UpstreamVersionFreeze (for precise, find out at PreciseReleaseSchedule), you need to follow this procedure.

Do I need to have a mentor to work on packaging things or become a MOTU?

The mentoring program is deprecated now. Please get in touch with DeveloperAdvisoryTeam in ubuntu to get pointers about the Ubuntu Development community

To contribute do I need to run <the current development release>?

Strictly speaking: yes. It's the only way to guarantee your fixes and packages build and work as expected in the development release that is currently being worked on.

UsingDevelopmentReleases explains how to do this in a safe way.

Packaging

What version number should my package have?

Ubuntu and Debian have slightly different package versioning schemes, for an explanation see the Packaging Guide.

Should my package have -0ubuntu1 appended to the end of the version number?

If the package is being newly packaged for Ubuntu and hasn't come from Debian then the Debian revision number should be 0 and the Ubuntu revision should be 1, so in that situation it would be -0ubuntu1. See the previous question for details.

How can I make multiple pbuilders? How can I make a pbuilder for <release name>?

The pbuilder-dist script in the ubuntu-dev-tools package does exactly that. Read the pbuilder-dist(1) manpage to find out how to use pbuilder with many different Ubuntu versions.

What options do I need for debuild to make a source package including tar.gz?

  • debuild -S -sa

Upstream already provided a debian-dir in the orig.tar.gz, what now?

  • Always ask upstream kindly to remove it.
  • At your option (if you need to remove a file from the upstream debian-dir you will need to remove the upstream debian-dir from orig.tar.gz):
    • Remove it from the tarball, renaming the tarball while doing so. Example: foo_0.2.orig.tar.gz would then be foo_0.2repacked1.orig.tar.gz.
    • Just modify the package as usual.

I need to fix a bug in the upstream provided source, modify the source or add a patch?

  • If the package already has a packaging system, make a patch and add it.
  • If the package does not have a packaging system and the patch is small, you can modify the source. It is an Ubuntu goal to keep diffs with Debian small and so if modifying the source makes a smaller diff than adding a patch system you should generally modify the source.
  • If your package uses cdbs, you ought to consider using simple-patchsys and use cdbs-edit-patch to make your patch in any case.
  • See PackagingGuide/PatchSystems for more information on patching

  • UbuntuDevelopment/PatchTaggingGuidelines has informations about tagging distribution patches

  • See http://distributions.freedesktop.org/wiki/Packaging/WhyUpstream for some tips on getting your change upstream and why this is important.

What does XSBC-Original-Maintainer mean?

When a package is changed in Ubuntu, the Maintainer field (in debian/control) is changed to indicate the Ubuntu team responsible for the Ubuntu specific changes (often "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" for universe packages). In order to ensure appropriate credit for the packaging work, the original maintainer is preserved in a new field: XSBC-Original-Maintainer. This is a user-defined field (X) which is included in the .dsc file for the source package (S), the .deb file for the binary package (B), and the .changes file (C).

When the Maintainer field is adjusted, the value of XSBC-Original-Maintainer should exactly match the previous value of Maintainer.

Licensing

Which license should I release the packaging under?

Ideally, under the closest possible license to that of the original software. "Packaging" includes patches made by the packager, and thus is considered a derivative work. Using the same license means that the patches can be easily incorporated upstream.

Which GPL/LGPL versions are compatible with each other?

Generally, as a rule of thumb, "GPLvX and above" is compatible with GPLvX, GPLvX+1, "GPLvX+1 and above" etc., but the aggregate will be subject to their common subset: for example, "GPLv2 and above" code aggregated with GPLv2 (GPLv3) software can only be distributed under GPLv2 (GPLv3, respectively).

LGPL libraries can be linked with just about anything, but if LGPL code is to be incorporated into a GPL work, it will have to be converted to the corresponding GPL version (LGPLv2.1 to GPLv2, LGPLv3 to GPLv3).

The FSF has a compatibility table at http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility.

Miscellaneous

What does <some acronym> mean?

Either


Go back to UbuntuDevelopment.
CategoryUbuntuDevelopment

UbuntuDevelopment/FAQ (last edited 2014-02-18 22:20:50 by kotux)