hi nick, On Mon, Jul 26, 2004 at 10:38:21PM -0400, Nick Lewycky wrote: > >i believe he means, "you can not even re-distribute the binaries, you > >must > >distribute an installer", similar to what users have to do for the > >non-free flash player or nvidia's non-free hardware acceleration > >binaries. > > Then we all agree. or at least understand what he meant, anyway. > dpkg doesn't, but that's mostly irrelevant. Debian Policy provides me > with enough detail to correctly track the files manually, by the postrm > and postinst scripts. My package does so. i think the majority of the -devel list would disagree with you on that point (or, i could be wrong :). i can think of a number of reasons this would be a bad idea. not being able to track what package owns your files, the possibility of your package conflicting with another package and overwriting its files (or vice versa), the possibility of something going wrong during install/upgrade (think: network error) and ending up with a very confused install state, and what might happen if the file list in said package changed in later versions... really, i'm not trying to an asshole, i promise. i'm arguing why as a generalization, i think this is a bad practice because among other things it entirely circumvents the package management system. > I consider the nvidia package to be Broken As Designed, and when I had > NVidia hardware, I avoided it simply because of that. Is there a good > explanation of why users should be required to have a complete debian > package build toolchain just to use a package? I am capable of changing > my mind. for most kernel-module packages in main, debian provides pre-compiled binary packages to compliment the provided stock kernel packages. users who have their own custom-compiled kernels, however, must build their own packages from the "foo-source" packages, which depend on said package build toolchain. with the non-free nvidia drivers, however, debian is not permitted to re-distribute the precompiled binaries, so all users must compile them regardless of whether they have a stock or custom kernel. so why not follow suit of the other foo-source packages? > I never said that the software was essential. Far from it, I explicitly > state that it's an optional, miscellaneous contribution. And I won't let > you turn this into the damned "remove non-free from Debian" debate. Even > Brandon needs a break. honestly, it wasn't my intention to start it such an argument. i do think that new software entering non-free should be viewed under a critical eye though, especially software as non-free as this and requiring questionable packaging practices. my reaction was caused by this: >>>Another one of Debian's essential interests is a commitment to its >>>users. Folding@Home has a community of around 300,000 users and is >>>growing. It was only a matter of time before the two groups intersect. which is an often (imho ill-) used argument. in this case, it seemed that you were arguing debian had a commitment to the folding users because there was some undetermined intersection of debian users, which irked me a bit. perhaps my reaction was a little pedantic, i apologize. > a) No, it'd be a disservice to the Folding community. Their FAQ explains > that they need to keep the code secret for scientific integrity: > > http://www.stanford.edu/group/pandegroup/folding/faq.html#project.source ah, the old security through obscurity :) > b) Yes, I plan to try that only if Debian refuses to accept the package, > which could happen if no one sponsors it. Honestly, I don't expect the > Pandegroup (Folding@home upstream) to respond to me at all. looking at their site, they don't offer their software in any other pre-packaged formats either, so you might be right. that brings up the whole other issue of having active relations with upstream... sean --
Attachment:
signature.asc
Description: Digital signature