Hi, On 15/06/13 09:30, [email protected] wrote: > On Friday, 14 June, 2013 03:26 PM, Emilio Pozuelo Monfort wrote: >> On 14/06/13 09:22, Emilio Pozuelo Monfort wrote: >>> ISTR recommending a package not in the archive was a bug, but I can't find a >>> reference. So if you would like to keep this that's fine with me as it won't >>> prevent migration of your package. Though perhaps you may want to downgrade >>> it >>> to a suggest. I leave that decision to you. >> Found the reference now, see >> >> http://www.debian.org/doc/debian-policy/ch-archive.html#s-main >> >> "must not require or recommend a package outside of main". >> >> You could downgrade it to a suggests though. > > > Hello Emilio, > > thank you very much for adding that information. I am certainly not trying to > keep that Recommends line around forever even though the package is gone. My > intention is to fully understand what you and Jeremy are trying to fix and to > make sure it is fixed in the right way. In particular I was tripped by the > suggested change not being to simply drop the recommends line but making > changes > to the build where the added patch 03_disable_evo_database.patch claims in the > subject that the evolution backend no longer works. All I can say is that the > last time I tried it (admittedly on Ubuntu precise) it was working just fine > IIRC. This might no longer be the case with the latest Debian and Ubuntu > releases which I only run in virtual containers on an as-needed basis.
I don't know what Jeremy did, but I never suggested to touch the build system or anything similar. From my initial report: "Your package recommends python-evolution, which is gone. Please remove that recommendation from your package." The only problem is with the recommendation. You can drop it or demote it to a suggests and everything will be fine then. > As far as the quoted policy is concerned, I believe that mostly concerns the > DFSG. A package in main should not recommend a package in non-free, for > example. Besides, python-evolution IS in main, just simply not in unstable. > So, it is my understanding that the gbirthday package in its current form does > not violate the policy. It is about that, but more importantly it is about having a self-contained suite. E.g. if a package in unstable depends on something that is not in unstable, then it *can't* be installed and violates Policy per the above. Similarly if a package in unstable recommends something that is not in unstable, it violates Policy as well. I think it is very clear. Emilio -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
