[Pkg-mol-devel] [Pkg-mol-commits] r152 - in mol/trunk/debian: . debian.mol-source

[Jörg Sommer]

Hello Gaudenz,

Gaudenz Steinlin schrieb am Wed 26. Sep, 23:39 (+0200):
> Some general remarks:
> - Please always also update the debian/changelog when commiting changes
>   (in the same commit)

Oh, sorry. I forgot to do this.

> Answers to the questions in your previous mail:
> * Why is a ~ in the version? ~ is a special character. I would use +
> 
> This is on purpose exactly because ~ is special. I used .dfsg before and
> the problem was, that when upstream introduced a 4th component in the
> version number d (the start of dfsg) sorted after 1 (the new version
> number component). I wanted to avoid this problem in the future. + would
> also be ok, but what if upstream decides to use + in a version number?

I would kill him. ;-) It looks like there no common practice to
separate the dfsg:

% grep '^Vers' /var/lib/apt/lists/ftp.de.debian.org_debian_dists_unstable_main_binary-powerpc_Packages \
  | grep -o '.dfsg' | sort -u
0dfsg
1dfsg
2dfsg
3dfsg
4dfsg
5dfsg
8dfsg
9dfsg
~dfsg
-dfsg
.dfsg
+dfsg

> Building the current svn HEAD in pbuilder fails with the following
> error. Please always test with pbuilder before commiting. The build
> works if you change the invocation back to
> KERNEL_SOURCE=/lib/modules/`uname -r`/build  $(MAKE) -C src/kmod/Linux/
> setup-common

Interesting. At me /lib/modules includes a symlink source.

But I looked in the Makefile and saw that KERNEL_SOURCE is not used by
the setup-common target. There's only a check if it is a directory. I
“fixed” it.

> On Tue, Sep 25, 2007 at 01:51:54PM +0000, jo-guest at alioth.debian.org wrote:
> > Author: jo-guest
> > Date: 2007-09-25 13:51:54 +0000 (Tue, 25 Sep 2007)
> > New Revision: 152
> > 
> > Log:
> >   ?\194?\183 Rearranged the targets in the file: clean, build, binary.
> 
> OK, if you think it's better like this. I don't mind. Please place the
> "rm -r modules" call in the clean target and not in the binary-arch
> target.

I've put it there, because I think a second call of binary-arch
(without a cleanup before) would fail. The right way is IMO to create
the directory or the tar.bz2 in the build target.

> >   ?\194?\183 clean:
> >     + Removed the dh_testroot. clean doesn't need root previleges.
> 
> Root privileges are not needed, you are correct. The advantage of
> calling dh_testroot here is that the build with dpkg-buildpackage or
> debuild fails earlier if you forget to call them with fakeroot. If you
> think it's better to remove the call I don't really mind.

Yes, I think it eases the call of debian/rules clean. :)

> >   ?\194?\183 Merged the configure and the build targets.
> 
> I'd rather keep them separate. This seems to be common practice. Is
> there any advantage in merging them.

I don't know. I see no advantage to split out a single call. It's more
a personal preference.

> BTW did you ever check the pci-proxy support or the debugger?

I thought the pci-proxy support is already enabled. I think it's very
usable to access the Airport Extreme Card. I don't know the debugger,
but I think we should build it.

> >   ?\194?\183 Added the get-orig-source target that fetches the upstream tar.bz2 and
> >     creates the .orig.tar.gz. This is what policy suggests in section 4.9.
> 
> Having this target is a good thing. But I don't like the way you
> duplicate code that is in the "make_orig_tarballs" script in svn. Please
> use this script in this target!

But that's not possible. The make_orig_tarballs script is not available
in the source. A user can not use it.

> One reason why I did not yet implement this target myself is, that mol
> is not the usual situtation where you just want to delete some non-free
> parts from the source, but you want to split the upstream tarball into
> several source packages. So this does not really belong into this source
> package any more than into the source of mol-drivers-macos(x).

Yes, I think we should put it there to, but remove there the stuff that's
not needed for mol-drivers-macos. I think every g-o-s target should fetch
the upstream tarball and build the debian tarball from it.

I like the g-o-s target, because a user can easily see what get's
changed and it is easy to adapt it to a new upstream release.

Bye, Jörg.
-- 
“Computer games don't affect kids. If Pacman would have affected us as
children, we would now run around in darkened rooms, munching pills and
listening to repetetive music.”
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-mol-devel/attachments/20070927/d96c6e7e/attachment.pgp