| Nick Lewycky 2004-07-28, 6:23 pm |
| sean finney wrote:
>
> hi nick,
>
> On Mon, Jul 26, 2004 at 10:38:21PM -0400, Nick Lewycky wrote:
>
> or at least understand what he meant, anyway.
>
>
> 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 XXXXXXX, 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 XXXXXXX.
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.
>
> 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-ment...7/msg00372.html
>
> 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:
>
>
> 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 XXXXXXX 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
<http://www.stanford.edu/group/pande...#project.source>[vbcol=seagreen]
>
> ah, the old security through obscurity
Guilty as charged, your honour.
>
> 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
--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|