Re: Bug#261257: ITP: folding -- Folding@home Client (install
sean finney wrote:
>
> 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.
Relax, you're not being an asshole. :)
Debian Policy chapter 6 offers a lot of guarantees on how the scripts
are called. The only thing that F@H offers is a guarantee that it will
restrict itself to the current working directory and subdirs. So I
simply blow that away on purge, and I remove the main program executable
on remove.
Technically, I can't let dpkg know what all the files are because they
aren't always known. It downloads cores from Stanford, with names like
"FahCore_79.exe". Of course, in the future, new cores will be released
with new names. I can't possibly list them all.
That's why I put it all in /var/lib; it's like a mail queue or some
other unpredictable directory structure.
> > 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 didn't mean the compiler, but rather the dependencies on dpatch,
debhelper etc.
For some reason, I always thought that an installer package should be a
proxy for the material it installs. That is, when you install it, it
installs the material. When you remove it, it removes the material.
Depending on the material can be achieved by depending on the installer
package.
Unfortunately, I seem to be outnumbered:
http://lists.debian.org/debian-mentors/2004/07/msg00372.html
> > 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.
Well, it was a reaction to an equally one-sided interpretation of the
Social Contract, not by you but by Guillem Jover:
"I've seen as well that you don't maintain any package yet, is this
the way you want to contribute, given that one of our essential
interests is the Free Software movement?"
Which was a wee bit inflammatory (relax Guillem, I don't think you were
trying to be an asshole either), so I decided to handle it by
misdirection instead of more flames. I mean, really, I'm volunteering
time and work here. I've contributed to the Free Software movement
before with both code and evangilism. I shouldn't need to defend myself.
I do need to defend the package though, and that's why I appreciate your
critical review. Debian offers a wide array of support for its non-free
material, equal to that of its Free siblings. This review process is
> > 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 :)
Guilty as charged, your honour. :)
> > 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...
Yeah, I know. I know. The good news is that the current material is good
enough that I shouldn't need to communicate with upstream. There are
other 3rd party folks who rely on F@H so if they goof something up, I
expect that they'll fix it soon enough. Fingers crossed.
Nick Lewycky
Reply to: