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