(dropping debian-devel, this is really not a technical issue) Matt Zimmerman wrote on 17/01/2006 20:44: > I would very much appreciate if folks would review > http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the > points that I raise there. I put some effort into collating the issues > which came up the last time and presenting them. Fine, quoting from there: > Ubuntu is a distribution based on Debian. Exactly. > 1. Most of the source packages in Ubuntu are inherited from Debian > unchanged (example: tetex-base). False. They are changed through recompilation. So let's assume you are talking about the source part only. Then the problem is that they aren't automatically updated as soon as their Debian counterpart is updated. So a Debian maintainer has no way to fix the package in Ubuntu. In my opinion, the maintainer field should be set to some Ubuntu individual or team even in these cases. But I would be fine with the maintainer field unchanged if the majority of Debian Devs would agree to taht. > 2. Some source packages in Ubuntu are modified relative to Debian. These > are assigned a version number of the form > "<Debian version number>ubuntu<ubuntu revision number>". Of those which > are modified, in most cases the modifications are trivial, such as a > library transition, Python transition or other dependency change > (example: python-adns, > http://people.ubuntu.com/~scott/patches/python-adns/python-adns_1.0.0-6ubuntu3.patch). > In some cases, the packages are modified more extensively (example: > several d-i components, such as partman > http://people.ubuntu.com/~scott/patches/partman-auto/partman-auto_41ubuntu1.patch). At the very least, for more extensively modified packages, you should definitely set the maintainer field to some ubuntu entity. But since you did modifications after the Debian maintainer did his, he had no way of approving your changes, so you should _really_ set the maintainer field to something inside ubuntu for all these packages you changed. Don't forget to suggest your changes to the Debian maintainer for future inclusion. Unless they are completely Ubuntu specific. But even then, suggesting them might help the Debian maintainer in the future. > 3. A small number of packages are created specifically for Ubuntu. These > are assigned standard version numbers. Of those, some have already been > adopted by Debian (example: pmount), some are expected to be adopted by > Debian at some point in the future (example: xorg), and some are not > expected to be used in a Debian context (example: ubuntu-artwork). Well, I don't see how these fit into the discussion. As they are created by Ubuntu and already carry an ubuntu specific entity in their Maintainer field, these aren't effected by this discussion, I think. > It is important, in particular, to account for the fact that Ubuntu is not > the only Debian derivative, and that proposals like yours would amount to > Debian derivatives being obliged to fork *every source package in Debian* > for the sake of changing a few lines of text. That's why I would be OK with the maintainer field kept as is if you really are merely recompiling the package. However: In that case you should have some mechanism in place to monitor updates to those packages in Debian and to merge those updates into Ubuntu if needed. Now, finally to answer your questions directly: > Given the above, the relevant questions would seem to be: > > If a binary package is built by a third party from unmodified Debian > sources, should its Maintainer field be kept the same as the source > package, or set to the name and address of the third party? I would prefer to see it set to the name and address of the third party, but I would accept it if a majority says this is not needed. > Should Debian-derived distributions change the Maintainer field in source > packages which are modified relative to Debian? If so, should this be > done in all cases, or only if the modifications are non-trivial? Definitely: Yes, they should, in either case. Simply for the reason that even seemingly trivial changes can introduce new bugs. Apart from the fact that a change which seems trivial to one person doesn't need to seem trivial to another. > I am interested in responses to these two questions from the Debian > community. cu, sven
Attachment:
signature.asc
Description: OpenPGP digital signature