Raul Miller <[EMAIL PROTECTED]> writes: > Daniel Martin at cush <[EMAIL PROTECTED]> wrote: > > What about a pine-installer package? > > > > This would be similar to the netscape3 and netscape4 packages of old - > > the user would be asked in the preinst to put the pine .orig.tar.gz, > > the .diff.gz and the .dsc files into /tmp (or $TMPDIR); if those files > > weren't there the preinst would bomb out, aborting installation. > > We didn't have the right to distribute the netscape3 and netscape4 > packages. We do have the rights to distribute qmail and pine sources. > > I don't think it's wise (good for the people who use debian) to discard > that ability (which we currently have).
I don't quite understand what ability it is that you think would be discarded. The ability to distribute everything needed to compile and install pine all at once? I don't see how this would not be accomplished by a pine-installer that asked to optionally download the required files. Or are you perhaps imagining the creation of some non-official Debian CD that would have the pine-src package on it - it shouldn't be too hard to program in a few alternative locations for the pine installer to look in before deciding that it should download the programs, and it could always ask the user for an alternative location before deciding to do the download. (the dangers of attempting to guess the source tree by looking at dpkg internals aside) Is there some kind of "pride in Debian" issue that makes it desireable to put everything needed for pine into .debs, or is there some hidden benefit I'm not seeing to a pine-src package that a pine-installer doesn't provide? Let me lay out my opinion of the differences of the effects of the two methods: Method pine-src: --------------- - the user who hasn't discovered debian-user or ftp.debian.org, but just has an official CD (and barring some unexpected marketing, official Debian CDs will be much more numerous than CDs mixing in non-free stuff) will conclude that pine isn't available for Debian. - the user on a high-enough speed connection to be using dselect's ftp method will see "pine-src" in the menu and conclude that that's what they need to install pine. - the pine-src package will be a huge thing to download each time a new pine .diff.gz is released. (the "three .debs" way seems incredibly convoluted, especially when a pine-installer can do the whole thing in a much cleaner fashion) - various people will get very upset about having the pine source twice on debian mirrors - a bit superfluous, no? Method pine-installer: ---------------------- - the user with an official CD will see the "pine-installer" package and will conclude correctly that pine has been packaged for Debian but that - the user on a high-enough speed connection to be using dselect's ftp method will see "pine-installer" or somesuch in the menu, note the description and choose to install it. Since the description will have said "this package will go fetch the pine source package if it's not already avaliable", the user will not be surprised when prompted with: Pine source not found; enter the location of the file pine_3.96L-*.dsc or press enter to get the latest version from ftp.debian.org [] (if the pine-installer is daring enough to parse /var/lib/dpkg/methods/ftp/vars this could be the ftp site the user had been using) - The pine package won't get updated each time a new .diff.gz comes out, unless a new pine-installer package also comes out. This is a slight inconvenience to the pine-installer maintainer. I don't think that the ability of a user to install pine using no knowledge other than that obtained by running dselect off the official CD should be discarded. I really think that getting pine-something into contrib (and therefore onto the Official CD) is an important goal, if having pine around is an improtant ease-of-use issue. Hmmm... what if the pine installer package contained the .diff.gz and .dsc files? This might still be an inconvenience to the pine-installer maintainer, but not much; I _think_ that the pine license allows the distribution of DFSG-free patch files, but this would also be something to look at. (I mean, I know that the license allow the redistribution of patchfiles, but does it allow someone to take code found in a patchfile and use it elsewhere? I think not, which would make the .diff.gz non-free, wouldn't it?) If including the .diff.gz forces the installer into non-free, then there's no point in doing it that way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]