On Sat, 28 Feb 2009 18:11:23 +0100
Sjors Gielen <mailinglist@dazjorz.com> wrote:
> I'm working on a Debian port to Cygwin called Debian GNU/kCygwin.
(I'm surprised you think it's worth it, the hardware can run Debian
without needing a port so why complicate things by keeping Windows
around?)
> I'm
> constantly taking an important Debian package like cdbs or graphviz from
> sid, then try to get it to build and work on Cygwin. For this, I have
> had to modify a lot of build instructions and some sources. Now, I have
> two questions:
Check how Emdebian Crush does the same job. We keep patches in SVN,
have a wrapper that applies the patches before dpkg-buildpackage is
called (because we're patching debian/rules itself) and feed bugs with
patches back to the Debian package when things settle down and the
patch is reliable.
EVERY time you change a package for any reason, the version must
change. Emdebian uses em[0-9] so em1, em2, em3 etc. and treat Debian as
upstream. Therefore, foobar_1.2.3-4 becomes foobar_1.2.3-4em1 and
foobar_1.2.4-1 becomes foobar1.2.4-1em1 - makes no difference whether
it is a Debian revision or an upstream release.
> 1. When I modify source, I should bump the version number, i.e. add
> "cygwin1" at the end of the version set?
Yes. That seems a bit long though - you are correct to use a [a-z][0-9]
format, just wondering if it should be [a-z]{2-3}[0-9].
> And, am I right to assume that
> this all happens automatically when I add an entry to debian/changelog?
No - you have to pass that version to debchange directly.
$ dch -v1.2.3-4em1
> 2. When I only modify build instructions (debian/rules or Makefile.in or
> so), should I also bump the version number? What about when these
> modifications do, or do not, change the actual working of the package
> compared to sid?
Change the version every time you do anything. Emdebian adds the em1
suffix to the version even if all we're doing is cross-building the
package without any changes whatsoever.
If you are cross-building, you should also change the version because
cross-building has mysterious effects on the compiled objects that are
not easily detectable merely be comparing the "working of the package".
(Note that Emdebian has no direct support for cygwin and I've no time
to change that situation.)
> 3. Should I put my (source and build) patches in debian/patches? If so,
> is there policy on the naming, e.g. 100_cygwin_buildfix or so? What if
> there is no debian/patches directory? (does this have something to do
> with quilt?)
No, you cannot use debian/patches if you patch debian/rules because
debian/rules is executed *BEFORE* the patches are applied. You need
completely external patches, as used in Emdebian.
> When I have completed the porting of one package and succesfully built a
> .deb package, dpkg-buildpackage only creates a list of .deb files and
> possibly .changes. When I want to put these .debs in a public apt
> repository (I still have to succesfully port apt), licenses say I should
> also add the original source including all my patches.
>
> 4. Am I right to assume dpkg-buildpackage does not modify any other
> files than the .deb in the unpack directory? (that's one level above
> foopackage-1.2.3)
It modifies the source package too, updating the .diff.gz or .tar.gz
for a native package.
> 5. If the answer to (3) is to put patches in a specific location like
> debian/patches and NOT in the .diff.gz, how do I make sure the .diff.gz
> is created correctly; i.e. how do I bundle my patches complete from the
> unpacked build source on my PC to the public apt repository?
The changes you make will appear in .diff.gz and are applied that way.
> And the last question:
> 6. If I think my patches are worth it, I'm sending them to the Debian
> bug-tracking system. However, not all patches are accepted: for example,
> this one[1] was refused because the maintainer didn't want to worry
> about things this patch fixes (case insensitive file systems).
> In such cases, where IMO the maintainer is just too short-sighted to see
> beyond his own wishes, should I just drop the case, forget about sending
> the patch upstream and leave the situation as it is? I'm thinking other
> people can be helped, and the patch *is* available in the bug report,
> it's just not merged into the real package.
> I've mailed debian-devel about it, but nobody actually responded with an
> action I should take. What do you think? Just drop it?
I responded on @devel. There is nothing you can do about this. Accept
it. Maintainers are in complete control of their own packages and if a
maintainer thinks that your patch is irrelevant, unimportant or simply
a nuisance, there's little you can do because cygwin just isn't
sufficiently important to Debian as-a-whole for anyone else to care.
FTR, cross-building generally has a low importance too. What I mean by
that is that if Debian needs a change that breaks cross-build support,
it is the cross-builders who need to adapt to the change. If
cross-building needs a change that has no benefit to Debian, there is
little pressure to include the change. Nobody actually obstructs you
deliberately, but the issue is not a high priority and other issues are
fixed quicker.
That is how it is and there is nothing you or I can do to change it.
Accept it and get on with what you want to do. There is no way that you
will get perfect cygwin support for every package you need. Not enough
people in Debian care about cygwin. IMHO, cygwin has a lower priority
than cross-building, simply because few Debian people care about Win32
support or have any desire to see their software running under win32.
Various Debian people might just not want to consider cygwin changes
because they have no possible means of testing the effect of the change
on the desired platform - I know I won't ever test my own code on
cygwin simply because I refuse to have any Windows code on my own
machines, ever. I've done Windows development and I have no desire to
return to that nightmare.
Personally, I have no desire to have any of my Debian or upstream code
on win32 and I would probably not have time to fix any cygwin bugs in
my packages. It just isn't important enough.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpNVJEuhyM2k.pgp
Description: PGP signature