Hi,
I have been following this thread with some bemusement. I
maintain the Debian package of fvwm, and yes, the divergence in the
./debian directory has caused an additional overhead for me. On the
other hand, this is what Debian developers are supposed to do, so this
is not a complaint.
On Tue, Mar 10 2009, Mikhael Goikhman wrote:
> [Start of friendly mode.]
>
> Reasons to remove debian/ from fvwm as I see it:
>
> 1) To make a work for one man easier.
>
> BTW, I think Manoj used GNU Arch in the past and it perfectly supports
> real merges and file/dir renames as well as the files with the same
> names, but different ids in the branches. I am not sure why there
> was a move to git if it does not support what is needed anymore.
Well, the way debian source packages work is that file deletions
are not tracked in the debian diff.gz file, so files deleted in the
official debian directory still show up on build daemons, and that is
confusing.
Secondly, it causes conflicts between branches whenever I try to
merge new upstream versions, and yes, I could resolve the conflicts,
but this is more error prone (the automated processes fail, and I see
no benefit to going through the exercise). git_load_dirs could be
improved upon as well.
> Reasons not to remove debian/ from fvwm:
>
> 1) To respect the work of the developers who added it for a very good
> reason, and spent basically thousands of hours to make it work well.
>
> Historically the Debian package came with its own setup and we had
> users complaining on our mailing lists about something that is not in
> our distribution.
>
> Andrei Mitrofanow with some of my help created this procedure to make
> it more flexible and manageable by the fvwm developers themselves.
> Initially he just wanted to create debs for fvwm-themes and wm-icons,
> and discovered that this would be either very hard or impossible,
> since the official Debian fvwm package at that time had some
> incompatible solutions.
A bug report would have been appreciated. I was not always the
maintainer of fvwm, but I try to respond to upstream requests.
> 2) To respect the users who use it. This whole topic was started
> because one user said this procedure is useful to him and wanted to
> improve it.
I suspect that Debian needs and conventions might indeed be
different here; we have more options enabled by default, rather than
probing the local system, because our build daemons are bare bones
machines until we install the dependencies. And since we have to
install most of the libraries we need, might as well provide the most
functional package we can: some user out there probably wanted the
functionality, and, compared to GNOME/KDE, the end result is still
pretty light.
> 3) To avoid one more dependency (git for the users? with possible need
> to resolve conflicts on update? and keeping git tree inside cvs tree?)
> It is much more complicated than the existing "make deb-inplace".
Firstly, you would only need ./debian and ./debian/common from
the Debian git tree. There is a simple recipe for doing this below. Not
real git fu is needed. However, if you do not want git at all, the
git.debian.org site has a facility that creates a tarball for any
commit and allows people to download it, so git or git-fu is not
required.
> 4) I think it is just fine to have two procedures, one that is
> maintained by us, especiallu if there are developers willing to
> maintain it, and the independent one, that conforms to the official
> Debian/Ubuntu/whatever policy.
While I find this duplication of effort, I am fine with this;
all it means is that I'll have to repack the fvwm original tarball to
remove the debian directory. And, unless y'all track the changes
happening in Debian policy, the upstream package might not install on
Debian -- which is why a co-operative effort to maintain ./debian would
be beneficial, in my eyes. But this is all up to y'all.
Why don't I use the minimal build system already present?
You have already touched upon technical policy (when to strip,
or not strip, packages, and other issues, and policy is a living,
breathing thing, and changes more often than y'all would like to change
fvwm). But there were a couple of other things as well.
The first was using autoconf in ./debian; this impacted
reproducability. Debian compile packages for 11 architectures, and the
HURD, and there is an expectation that the package is uniform across
the architectures (this is separate from the application behaving the
same across the arches). Having a different package based on the buid
daemon or the security team build system is generally unacceptable in
Debian; and people frown upon automated creation of packagihg rules.
The second was that we were using different build systems; and
there list of files used in upstream and debian builds were
overlapping, but not identical. This is confusing to people (think
again the security team), and caused conflicts in my SCM of choice
(though I could have sucked it up and dealt with just that).
I have a common build system for the 30-odd packages I have,
and if debian conventions and policies change, I often can apply the
same patch across the packages. Having fvwm, or otehr packages, have
a different upstream makes things harder for me, and impact negatively
the time I have to take care of packages.
In any case, I would appreciate suggestions and improvements for
the official Debian package as well, and also would appreciate help on
some of the bugs reported on the page:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=fvwm;dist=unstable;repeatmerged=0
Thanks for working on fvwm.
manoj
--8<---------------cut here---------------start------------->8---
REPO=git://git.debian.org/~srivasta/debian/debian-dir.git
cd <fvwm-*/>
mkdir debian
cd debian
git init
git remote add -t fvwm -m fvwm -f origin $REPO
git pull
git submodule init=20
git submodule update
--8<---------------cut here---------------end--------------->8---
--
I'd never join any club that would have the likes of me as a
member. Groucho Marx
Manoj Srivastava <sriva...@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
