Josselin Mouette <[EMAIL PROTECTED]> wrote: > Creating debs easily is a good idea if done correctly, but only for > packages that will eventually enter the archive. It's a very bad > idea to encourage people to build their own versions of Debian > packages. It would lead to a horrible cluttering of package sources, > and to the disappearance of any coherent versioning scheme.
As a fellow Debian Developer, I say, "Hogwash!" If Debian isn't providing *.deb's, then there's nothing wrong with upstream providing their own, regardless of vaporish eventualities. In fact, it's presumptuous to assume that Debian has *any* control over upstream's practices. I applaud Phillip for his assistance in trying to resolve the issue at hand. I for one encourage upstream to provide packages in any and all formats that they're willing to. All the better if the package is policy compliant, has sane dependences, and compiled against latest stable and unstable archives, but these are by no means a requirement. Given that Debian developers are volunteers and may not be as responsive to user's bug reports as upstream may be, the centralized nature of Debian you tout as being so grand isn't always so. I admit freely that had I more time, I might be able to respond more quickly to bug reports and feature requests. (Not to mention the politics and overly-strict, glacial policies.) So, I again encourage software developers to provide packages to any system they might want to support, and if they need help with packaging software for official inclusion to Debian, there are plenty of developers and new maintainer candidates willing to help. > However, if a semi-automated way to produce Debian source packages > is available, like it is for CPAN modules, it can only be a good > thing, as it will be used to make loads of packages that can enter > the archive. And there's no reason why all these python modules > couldn't enter the archive. Agreed. > ...You seem to forget your software isn't the only one out there; Presumptuous, shortsighted troll, and totally uncalled for. In fact, I believe Phillip, et. al. have been arguing the exact opposite. Folks, we don't all act this way. > we are providing a centralized way to get feedback, redistributing > it when necessary. This makes things much easier for users when they > have only one way to give feedback. ...which can have response problems proportional to the time investment of the developer maintaining the package. > ...You're going to use the features as soon as they are available in > the release. And releases are available in Debian unstable. s/are/may be/ Of course, that is if we can come to some sort of technical agreement here. > You're mixing things again, and again, and again. Debian > dependencies should NOT be mixed with lower-level dependencies. It depends (no pun intended -- O.K. maybe a little), and you state so in your next sentence. > A clean way of doing things would be a shlibs-like mechanism. For those unfamiliar with such terminology, shlibs is a debhelper script that heuristicly resolves dependencies found at package build time and then updates the appropriate field in the binary package(s) built for the source. In fact, I believe this has been suggested a number of times in this thread already. > However, it would require dependencies to be written only in > metadata files. As I understand it, they can also be asked directly > in python code, in which case there's no reliable way to tell a > package needs another package. Yet there's no reason to exclude the possibility of creating a Debian-specific hook in for easy_setup/setup.py to resolve these introspectively as well. Regardless, it's up to the packager to add appropriate package dependencies that cannot be resolved by automated scripts. This is not a new issue or one isolated to eggs. > That can be done in the unstable package. However, you're still > going to get complaints from sarge users because your software won't > see the stable ElementTree package. The same goes for RHEL4 users. Not an issue. Sarge (stable) users can get backports of all their favorite bleeding-edge software like they always could through upstream developers who package their own *.debs or through interested Debian developers who upload to sites such as http://backports.org. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
