I must have missed something. What is wrong in my statements? What file is rejected by Debian and why? What in this package contradicts the debian policy? I not only mean the letter of the DP but also the rationale behind it. What is wrong with this particular package given that ows is in Debian till 2007 and nobody complained?
1. Upstream main author is David Villa, which clearly stated *his* release policy and clearly refused to change it. I try to respect upstream opinions as much as Debian allows it. 2. The package maintainer is Cleto Martin, also a developer of atheist. His commits go directly into the svn repo. There is no separate branch for packaging because, as the *main* upstream author requires, package version is also changed when the debian directory changes. Therefore this is indeed a Debian native package. It may posibly be turned into a non-native package but it would require a fork, which in my opinion is much worse than this. 3. The versioning scheme although not the most orthodox one does not create problems for Debian. No need for epochs and no problems in case of debian-only related changes. For me it is just a matter of inconvenience for them. Could you be more precise on the problems you forsee for Debian? 4. I consider the package itself to be a small utility but extremely convenient for many people. Therefore I think it should be part of Debian (Debian Social Contract #4). 5. The maintainer *is* one of the upstream developers with commit rights to the atheist repo but he is not entitled to change the release policy. Therefore if upstream ships a file that Debian does not want to include anymore then Cleto Martin, the maintainer will remove it from upstream repo. It works as long as the maintainer is an upstream developer and there is a real commitment to develop a Debian package. That is precisely what a native package is. 6. Having a discussion like this in a place like the BTS is worse than having the same discussion in debian-devel or debian-private. As you can imagine, people which are so strongly opinionated on their release policy may easily get angry at such loose argumentation against their way of doing things. Should Debian require the package maintainer (an upstream developer) to remove the debian directory from upstream source to introduce it afterwards in the diff? Wow, this really sounds tough. If upstream author writes a sentence "if not in_a_Debian_system(): exit 0" then we would consider it a native package? How many debian dependencies must be introduced in order to consider it a native package? No joking, these are the complaints I heard today. Should Debian require an empty diff to go along the package for its whole life? This one is easier to swallow. Is there any other rationale behind native packages than trying to avoid empty diffs? Note that using nativeness to infer "debian infrastructure packages" is plainly wrong. Let's just imagine apt is ported to work on RPM repositories. Sounds familiar? Should we turn apt into non-native now? On the other hand having this kind of discussions on a BTS is just faking the stats. One more serious bug in the back of Debian distro. No wait it is closed. No, wait, it was reopened as a serious bug. No, wait it is wishlist. 9 follow-ups. This one must be a tough bug! Is it? Come on, this is a small simple package which just happens to have an unusual name and an unusual release policy. But it is still useful nonetheless. I do believe that there are hundreds of bugs which require more attention than this one. But since it seems to be such an attractor I propose two actions: 1. I'll try to convince the maintainer to turn this package into a non-native package with an empty diff. It sounds silly to me but it seems way better than splitting upstream source as proposed by Luk. What Luk propose would be equivalent to deny anybody the right to make a program ready to be used in Debian. 2. I urge you to reconsider having this discussion in a more appropriate place. Cheers, F. Moya
