Differences between revisions 2 and 4 (spanning 2 versions)
Revision 2 as of 2012-06-29 02:47:18
Size: 1463
Comment: Condensing items from debian-devel discussion: Improving our response to "duplicate" packages in Debian
Revision 4 as of 2020-11-07 12:25:24
Size: 1765
Editor: NickBlack
Comment: spelling of -> off
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
/!\ this page should be merged into the [[http://www.debian.org/doc/manuals/developers-reference/|developer's reference]].
Line 3: Line 5:
Even though ITPs are usually welcomed by Debian community, in some cases it is wise to research first either your time is worth the effort. You might be better of finding an alternative and helping out with its maintenance in Debian. Even though ITPs are usually welcomed by Debian community, in some cases it is wise to research first either your time is worth the effort. You might be better off finding an alternative and helping out with its maintenance in Debian.
Line 6: Line 8:

Find out if the software already exists in Debian. The existing package could have a different name to what you might expect, so do your search carefully and exhaustively.

/!\ this page should be merged into the developer's reference.

An Intent to Package (ITP) is a Debian bug report of the Work-Needing and Prospective Packages (WNPP) family. See WNPP for further info.

Even though ITPs are usually welcomed by Debian community, in some cases it is wise to research first either your time is worth the effort. You might be better off finding an alternative and helping out with its maintenance in Debian.

Before filing an ITP

Find out if the software already exists in Debian. The existing package could have a different name to what you might expect, so do your search carefully and exhaustively.

Please research how many similar software packages are there actually in Debian, in what shape they are, whether they have active upstream and downstream maintainers. Such knowledge might prepare you to defend your ITP in favor over existing alternatives.

If similar (mature) alternatives exist, before packaging consider contacting upstream asking why they write this software. Maybe they can be convinced to combine their efforts with upstreams of similar packages to avoid duplicating the efforts and guaranteeing longevity of the combined project.

Reasons why a new package might get rejected nevertheless

Especially if the archive already contains analogous packages, following reasons might be presented

  • The software is very immature (version 0.1-alpha or something like that).
  • It's a simple script or very small program, and should be merged (either upstream or downstream) with another package.
  • It really is an exact duplicate or a fork of another package with almost no changes to the original.