Dear Francisco and Cleto (I expect),
I think you clearly are misunderstanding a lot of stuff in this bug report. Your first answer was kind of violent as if you felt attacked for a bug report, I am sure it was not your intention but it is read in that way. Having bug reports in your packages is something perfectly normal in Debian and it is not bad, what is bad is not trying to address them in any way. Actually, having bug reports is a signal somebody is using the stuff you are packaging. By the way, it is not your package, but since you are the sponsor, I understand you feel resposible about it, which is quite fine. Let's see if I can explain better and maybe more lenghty what several people have tried to explain in this bug report. On Fri, Aug 28, 2009 at 11:22:08PM +0200, Francisco Moya wrote: > 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? > Since you do not quote here what you are answering, I am not sure at all what are you answering. It is usually nice quote exaclty what you are answering, it is one of the problems I have found to follow and understand you correctly in this bug report. > 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. > You do not have to change David's release policy at all. Actually, in this case, for what I have seen, David does not have any release policy, he does not release tarballs, and even if he did, you are not affected but his release policy to be forced to ship binary packages. For what I have seen in the package, the versions that are being uploaded are "numbered" after the date YYMMDD from a checkout of the code in the SVN and this code include a debian/ directory. Let me explain you the way this is usually handled in Debian: CASE A) (easy case) When upstream release tarballs with the debian/ dir. This happens from time to time. Maintainer usually ask upstream to drop this directory from the tarballs and in the meanwhile (or if upstream just do not care), the maintainer repackage upstream's tarball to remove this directory. CASE B) (complicated case) upstream does not do releases at all and has debian/ in their repo. It seems to be the case here. In short, maintainer do a svn checkout, version it someway, package it and upload it. More lengthy: since there are not releases maintainers ned to version it, usually people start with a 0 and use the svn revision, for example, for the revision 56 of atheist, you could number it: 0.svn56 or 0.0.svn56, so it indicates in the "version" number exacty what revision is, which is quite handy when bug reports are filed to upstream. Using the date as it is being used in atheist is not a good idea, what if you need to do 2 or more uploads in the same day due to upstream changes? If in the future upstream starts releasing and it breaks your invented revision number, you can use an epoch. Whan packaging, packager put this fictional version number and then the packaging revision with "-X". About the debian/ dir, you just ignore it and if it is the case you are using that debian/ then you add it later. In this case, of fictional versions it is a very good idea ask your sponsoree add a get-orig-source: rule in his debian/rules, so you can fetch the code exaclty as the sponsoree did and just the version he wants to upload easily. No, you won't find about get-orig-source: in the policy, that does not mean you can not use it, if you google it you will see how useful it is for a lot of people, even for one of the policy maintainers: http://www.eyrie.org/~eagle/notes/debian/scripts.html there you can find some info of how to implement and use the get-orig-source: target. And you know what it is very good about get-orig-source in this case? Since upstream does not release tarballs and users do not know exaclty what you are distributing in your tarball, checking the rules they can know exaclty. Imagine upstram is uploading the pdf files with documentation to the SVN while you generate them in build time. You do not need to fetch them. If there is something you should convince upstream about it is releasing tarballs of his software periodically and not ship the debian/ directory with some versioning scheme. Then you solve totally this problem. Advantanges of a package not being native for a random user: - When user see the upload is -2 -3, etc, users know it is NOT a new upstream relase and updates should not be big, just reading changelog will know exaclty what was changed. - When debian is frozen, you won't be allowed to upload a new upstream release. - When you see this versioning number, you think it is not a package developed only for Debian. Maybe upstreams only care about Debian, but if the software is usful it will be picked by other distros. > 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. > He can perfeclty maintain the debian/ directory wherever he wants, no need to fork at all. Just do as mentioned above... And no, this is not a debian native package, it is not software developed direclty for and in Debian. Again, this is explained above. BTW if Cleto is developer of atheist why he does not appear in debian/copyright? You mentioned earlier in this thread upstream was David Villa (message 44). And David happens to be also a Debian maintainer. > 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? > Read above. > 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). > While honestly I still do not understand what the program does, nobody in this thread had doubt of the usefulness of this piece of software. > 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. Nothing to do here, again, explained above. > > 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. This is the only thing annoys me about the whole issue. In Debian we discuss the stuff, we ask and we argue. You are the only who has get angry here and did not want to discuss. The BTS is being used exaclty for what it has been created, report issues and discuss about them. > 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. > No, upstream can have in their repo what they want. > 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? > I would answer to this but it is not really coherent.... > 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. > The policy is a great tool we have, but there is something called "usual (best) practices", and you do not see very familiar with them (*). When you got feedback in this bug report from several other developers, it is nto because we wanted to annoy you, it is because we saw you did not know about this and wanted to *help* you. All this said, the policy you seem to use so literally is not clear about when a package should be native. I encourage you to open a thread about this in -devel and/or -policy and help to make it clearer. If you want my personal opinion: we should kill the concenpt of native package. Hope this helps, Ana (*) quoting text in bug report, how the bts is used and the alike. This is not about technical competence at all, it is about experience in Debian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
