On 05/16, Mark Martinec wrote: > IMO the distribution-specific packaging stuff has no right to be > kept in a generic Unix/Linux/Windows package like SpamAssassin > and should be wiped out entirely. The package maintainers know > their job and their distribution most intimately and should have a > full jurisdiction over their packaging. Having two alternatives offered > is just confusing to end-users.
The reason I think it's useful to have the debian build stuff included is for people who want to use versions that have not yet been packaged by distributions, but want a cleaner install than "make install" or cpan provides. You just run "dpkg-buildpackage" from the directory extracted from the tarball and get a nice clean binary .deb package. My hope is to keep the debian build stuff in SpamAssassin's source repo in sync with the released Debian packages. Which is looking pretty easy. And I'd ask the Debian maintainers to help. RedHat packaging stuff is included, and, I believe up to date (spamassassin.spec, spamd/redhat-rc-script.sh). > It would be safer to leave any changes in this area to 3.4. Yes. But can you actually think of any way it would negatively impact anything in 3.3? On 05/16, Kevin A. McGrail wrote: > If we go the route you are saying, where did those files come from > and what is their licensing, etc.? The files come from Debian. It looks like the packaging information gets released under the same license as what is being packaged, so: Apache 2.0. (Ubuntu is using the unmodified package from Debian, since (at least) 3.3.1.) On 05/16, Noah Meyerhans wrote: > On Mon, May 16, 2011 at 02:08:54PM -0400, [email protected] wrote: > > I'd like to wipe the existing directory in trunk, and copy the current > > version over from the Debian / Ubuntu package (which is a newer > > version than the one I used for daily builds). What do you folks think? > > +1 (speaking as the debian package maintainer) Nice. If we can get your packaging and the upstream repo in sync, could you open a bug against spamassassin and attach a patch whenever you change it? > > The existing Debian packaging includes a pkgrules directory containing > > a copy of the rules. I'm thinking that should just be eliminated? > > Maybe run sa-update from the install script? > > I don't want to add an install-time dependency on a functioning internet > connection (I know this may sound silly to some people), I'm actually not entirely comfortable with install-time dependencies on the internet either. > and I want > spamassassin to be functional upon installation, so I prefer to avoid > running sa-update during installation. > > I only recently re-subscribed to this list, so I'm not sure what the > latest plans are, in terms of distributing a rules tarball. I've seen > some posts on this list that suggest that there may be a growing trend > toward no longer distributing the rules tarball. If that happens, I > would likely include a snapshot of the latest ruleset as distributed by > sa-update. Good enough for me. > I'm not opposed to adding a debconf note to the postinstall script > recommending that people enable automated sa-update rules. The > framework for doing so is included in the package, but disabled by > default. That would be nice. We definitely expect people to be running sa-update daily at this point. Is there a reason not to enable it by default? -- "Every normal man must be tempted at times to spit upon his hands, hoist the black flag, and begin slitting throats." - Henry Louis Mencken (1880-1956) http://www.ChaosReigns.com
