> Add /debian/ to MANIFEST, remove it from MANIFEST.SKIP
> 
> 6 months ago I copied the latest Debian / Ubuntu (they've been the same for a
> while) packaging info ( /debian/ directory) into trunk, replacing an obsolete,
> broken /debian/ directory.  Around that time, /debian/ was also removed from
> the MANIFEST / tarball releases.  

...

> My reason for wanting to include it in the releases is because there have been
> numerous times in the past where I have needed to install something from a
> tarball, and been very pleased to find an included /debian/ directory allowing
> me to cleanly build a .deb instead of dealing with the other less pleasant
> options.  

Just to clarify, /debian/ was never in a previous release that I can find.  It was added to support launchpad builds in trunk in Mid-May.

The MANIFEST however was incidentally edited from work on this bug https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6593 in Mid-May.

I then found including /debian/ wasn't in line with https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6647 to add the files to trunk and the docs at http://wiki.apache.org/spamassassin/SyncDebianPackaging which said to download trunk.

I then found issues when trying to fix hudson/jenkins because of MANFIEST and MANIFEST.skip issues which led to debian having been added to the MANIFEST.

So I then removed /debian/ from the Manifest in Late-May in line with the purpose being to support launchpad and be consistent with getting rid of OS specific items in releases in the long-term.

If you read the chain of emails at http://old.nabble.com/Updating-debian-build-directory--td31631485.html, it's pretty clear that having it in trunk but not in releases was a compromise in line with the consensus.

Synopsis: I am +1 for the tree remaining in trunk.  However, I'm leaning towards removing all of the OS/distribution specific stuff from releases as discussed prior and so I consider the current MANIFEST correct but will withhold voting for others to chime in.

(In reply to comment #0)
> believe the previous objections were mostly objections to including a /debian/
> directory that was not maintained, or was different from what the Debian
> maintainers are providing, neither of which is currently relevant.

> Some of the previous relevant conversation: 
> http://old.nabble.com/Updating-debian-build-directory--td31631485.html

Did you carefully re-read that thread before filing this bug?

Even the debian maintainer Noah Meyerhans was in favor of dropping it entirely, rather than getting it synced, since it won't help to keep it fresh in the
future.
  http://old.nabble.com/Re%3A-Updating-debian-build-directory--p31632268.html

I won't even consider this, unless the debian maintainers are in favor of it.

Other than that, there are quite a few -1 on distro specific stuff in the referenced thread.

(In reply to comment #1)
> Just to clarify, /debian/ was never in a previous release that I can find.  It
> was added to support launchpad builds in trunk in Mid-May.

Oh, thanks.  I thought it had been in the MANIFEST previously, but I confirmed your right, it's not in previous releases. 


(In reply to comment #2)
> Did you carefully re-read that thread before filing this bug?

Yes, a few times.

> Even the debian maintainer Noah Meyerhans was in favor of dropping it entirely,
> rather than getting it synced, since it won't help to keep it fresh in the
> future.

It'll help people who, for some reason, feel a need to install from a tarball on a Debian based system.  

> I won't even consider this, unless the debian maintainers are in favor of it.
>
> Other than that, there are quite a few -1 on distro specific stuff in the
> referenced thread.

Could you tell me your reason for objecting?  Other than just other people's opinions, which I'm not sure I agree with your interpretation of.

It's isolated in its own separate /debian/ directory, nice and tidy, and I'm maintaining it.  As far as I can tell there is no harm, and there can be some benefit.

(In reply to comment #3)
> > I won't even consider this, unless the debian maintainers are in favor of it.
> >
> > Other than that, there are quite a few -1 on distro specific stuff in the
> > referenced thread.
> 
> Could you tell me your reason for objecting?  Other than just other people's
> opinions, which I'm not sure I agree with your interpretation of.

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.

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 believe?

> 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.
> http://packages.qa.debian.org/s/spamassassin.html

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, darxus@chaosreigns.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 http://wiki.apache.org/spamassassin/SyncDebianPackaging
It looks like this:

svn checkout http://svn.apache.org/repos/asf/spamassassin/trunk
wget http://ftp.de.debian.org/debian/pool/main/s/spamassassin/spamassassin_3.3.2-2.debian.tar.gz
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/
rm debian/patches/50_sa-learn_fix_empty_list_handling debian/patches/85_disable_SSLv2
vim debian/patches/series
# 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 <dom@earth.li> 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)


My summary:

* 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 documented.
* I'm actually maintaining it.

No one to sponsor and keep changes in sync so it doesn't justify being in a release but will stay in trunk.