|Main Archive Page > Month Archives > spamassassin-dev archives|
What about moving /debian to contrib so there is no misunderstanding
it's not an officially maintained part of SA?
Beyond that, we've got so many fish to dry that worrying about adding
things isn't high on my agenda right now.
-------- Original Message --------
Subject: [Bug 6704] [review] Add /debian/ to MANIFEST
Date: Tue, 22 Nov 2011 18:30:24 +0000
--- Comment #5 from Darxus<Darxus@ChaosReigns.com> 2011-11-22 18:30:24 UTC ---
I don't expect many people to read this entire comment. What I hope people
will read is this: Adding /debian/ to release tarballs has the benefit of
allowing people to cleanly and easily build a .deb package from any tarball.
And as far as I can tell, there is *no* disadvantage, primarily due to the fact
that if maintenance ever becomes a concern, they are immediately resolved by
just deleting the entire directory. Nice and clean. What are the reasons for
not including it?
(In reply to comment #4)
> I did not object and vote -1 myself. I summarized the previous thread, and
> pointed out that others clearly expressed they are against it. KAM wrote in the
> referenced thread:
> "we now have Warren, Mark, Noah and Myself weighing in recommending that
> the debian (AND I believe the redhat stuff) be removed."
> I consider these previously stated objections by SA devs, deb and rpm package
> maintainers to still hold. Unless they now state otherwise.
> If you do not agree with my interpretation of the previous discussion, please
> provide clear references and arguments. Not agreeing with me is all fine and
> your right, but merely disagreeing won't help change my mind.
When those objections were stated, the debian directory had not been maintained
in 6 years, and was completely unusable. Since then I have kept it current for
5 months, and thoroughly documented the process. So the situation is now
vastly different from when these people recommended removing the debian
directory, so I don't think their recommendation still applies.
I really think it's a waste of time to to address everybody's concerns from a 6
month old conversation which I don't think applies. But there have been no
votes so far either way, so here we go:
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.
I'm curious where this comes from. I assume it must be aversion to decreasing
maintainability. But I think if there were a small patch that made SA work on
windows, or FreeBSD, or anything really, that SA didn't work without, it would
be applied. That's not the case here, but I don't understand what the reason
is to object to it just because it's only relevant to Debian based Linux
distributions. If it were messy, poorly documented code intermingled
throughout all of SA that made the whole thing more difficult to maintain, and
were difficult to revert, and there weren't multiple people actively
maintaining it, that I could understand. But if this ever becomes
unmaintained, you can just wipe the /debian/ directory. Nice and clean.
So, Mark, why do you object to distribution-specific packaging stuff?
I just made the connection that Mark is the FreeBSD maintainer, an OS that,
unlike Debian and RedHat, keeps its packaging information separate, in Ports, I
> 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.
Which is why I'm using an exact copy of what the package maintainers are
producing, with the exception of very clean removal of the few Debian patches
that have already been committed to trunk. This isn't a different alternative,
it's an option to build a clean .deb from any tarball or source repository
anybody feels a need to use, using the same packaging information.
On 05/16, Noah Meyerhans wrote:
> Sorry, I actually mis-read your proposal. I agree with Mark Martinec's
> suggestion that all distro-build stuff be dumped. It's not needed and
> is not generally useful (especially when it is as stale as it currently
> is). Copying the current stuff from the Debian package will solve the
> immediate issue of the debian/ directory being stale, but won't do
> anything to keep it fresh in the future.
This was Noah's objection. The Debian maintainer. His objections:
"especially when it is as stale as it currently is"
It's no-longer stale.
"Copying the current stuff from the Debian package will solve the immediate
issue of the debian/ directory being stale, but won't do anything to keep it
fresh in the future."
I'm maintaining it - that's doing something to keep it fresh in the future. I
also documented the hell out of the process. It's just a few commands, very
easy. And if it gets back to the problem of not being fresh, it can just be
deleted. No additional work ever needed by anybody (the deletion of the
/debian/ directory was already going to happen because it was there and stale,
and I prevented the need for that).
On 05/16, Adam Katz wrote:
> First, I'm a big Debian fan. If we're including the RPM stuff, we
> should include the DEB stuff. I agree with Darxus in that it is indeed
> quite useful and doesn't create clutter or wasted bits since it is in
> its own well-marked directory and is very small.
I appreciate that.
> That said, its presence in our releases implies WE are supporting it.
> While I would prefer it stay, I have to ultimately agree with Mark (who
> happens to also be the FreeBSD package maintainer) when he said:
> > The package maintainers know their job and their distribution most
> > intimately and should have a full jurisdiction over their packaging.
Best of both worlds. Package maintainers have full jurisdiction over
packaging, and I'm keeping trunk up to date with their packaging.
> We have the DEB pieces in our source tree too, though Noah Meyerhans,
> the Debian (upstream -1) maintainer is not an SA developer. Duncan
> Findley is both a Debian and SA developer, but seems dormant in both.
> I'm behind the ball in my plan to get Debian developer status. Based on
> this, we should probably remove the debian directory.
So Adam's recommendation to delete /debian/ was based on an expectation that
trunk's /debian/ couldn't be kept in sync with the Debian releases. I believe
I've proved that wrong.
> The clutter point is well taken too; even assuming another sufficiently
> popular system has a similarly small and segregated footprint and a
> maintainer willing to sync things up, there's the question of how
> valuable it is. RPM and DEB are special cases because of large number
> of derivatives that pull from Fedora or Debian in addition to the
> non-derivatives that go direct, like Mandriva, SUSE, and Fink (OS X).
The packaging that Debian and Ubuntu uses is identical. I expect it to work on
all other Debian based distributions.
On 05/17, John Hardin wrote:
> On Mon, 16 May 2011, email@example.com wrote:
> >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.
> Or the RPM equivalent. I agree.
John Hardin likes having the usable packaging info.
On 05/17, Warren Togami Jr. wrote:
> I have no opinion about removing the /debian/ directory, but the
> .spec file should be removed as it benefits nobody.
Warren never actually recommended removing the /debian/ directory. Just the
no-longer useful RedHat stuff.
I don't see where Kevin actually explained his objection. It sounds like his
primary concern was the implication that because it's present in the source,
it's current. And I'm keeping it current.
I think there is some misconception that there is more work involved here than
there actually is. Maybe because nobody has read my documentation at
It looks like this:
svn checkout http://svn.apache.org/repos/asf/spamassassin/trunk
tar -zxvf spamassassin_3.3.2-2.debian.tar.gz
cd trunk; find debian -type f | grep -v .svn | xargs svn rm
cp -a ../debian/* debian/
# delete the two lines containing the filenames just rm'ed
That's *all*. "svn diff" to generate a patch. Updating the MANIFEST is as
simple as "find debian -type f | grep -v .svn | sort" and editing the MANIFEST
to paste that in where the old debian files were listed - also documented on
the same page.
And the Debian maintainers made one significant change in the last half year,
disabling SSLv2, which was then applied to trunk. The other two changes were
just copying in an update of the SA source for the 3.3.2 release, and removing
a dependency on the libdigest-sha1-perl package:
3.3.1-2, by Noah:
* Disable SSLv2 support due to its removal from OpenSSL (Closes: 622053)
(which was then applied to trunk)
* Apply a patch from Dominic Hargreaves<firstname.lastname@example.org> to register
spamassassin for the perl-major-upgrade trigger (Closes: 619817)
* Bump standards version to 3.9.1.
3.3.2-1, by Noah:
* New upstream rc release. (Closes: 615590, 626191, 630327, 626751, 631583)
* Bump standards version to 3.9.2 (no changes)
* Add a README.source indicating that our orig.tar.gz differs from
upstream in that we need to delete their debian/ subdirectory.
* Delete patches that have been incorporated upstream.
3.3.2-2, by Noah:
* Remove dependencies on libdigest-sha1-perl, since it's being
removed from Debian. (Closes: #629612)
* The debian packaging info is isolated, and easy to remove by just deleting
the /debian/ directory, so it adds no additional maintenance work to SA.
* It has a benefit to people who want to install from a tarball on a Debian
based system, allowing them to easily and cleanly build a .deb package.
* It doesn't add significantly to the size of the tarball releases.
* It's extremely easy to keep updated, and the process is thoroughly
* I'm actually maintaining it.
-- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.