On Mon, 26 Nov 2012 16:24:32 +0000 (UTC) Thorsten Glaser <t...@mirbsd.de> wrote:
> >Just what is wrong with old-style debhelper like: > > Not much, other than the time a cowbuilder actually spends building > the code, versus the time spent installing the B-D and doing several > debhelper operations which – on m68k m68k is not a Debian architecture, it's requirements don't matter to the rest of Debian. Keep a fork of your code in a local repo for m68k, don't contaminate the rest of Debian with artificial requirements which have nothing to do with Debian release architectures. Believe it or not, I've done as much if not more work on slow architectures than you have, that's why I do a lot of cross-building. > And that’s what I’ll be uploading to experimental later. Sorry, that wasn't clear - you're planning on uploading old-style debhelper packaging for pax to experimental? If yes, then thank you. Is that upload tagged to close this bug? Use of old-style debhelper throughout debian/rules & .install files etc. would be a suitable fix. > Despite > that, I state here, for the record, that I believe I am entitled > to do this. Entitlement doesn't mean that it's the right thing to do in all situations. I'm entitled to upload all manner of rubbish to the archive - or to seek the removal of all manner of rubbish already in the archive - but I listen to my peers and contribute code which uses methods which help my colleagues to debug not only my code but my packaging. > Oh, another thing that’s “wrong” with it: I wanted to build mksh on > architectures where debhelper – or anything Perl, for that matter – In that case, you can't use dpkg-architecture, dpkg-shlibdeps, dpkg-gencontrol - all of which are part of your personal build system and any packaging system based around Debian. So, what you mean is that you want to build the upstream code and install it directly from the Makefile - fine, no problem with that. You don't need dpkg, perl or pax to do that. If you do want a .deb to do that, cross-build it - at which point, ooh, look, perl is installable just fine. Thankfully, it's not necessary to cross-build perl to cross-build things which use perl as build tools. See my perl-cross-debian work for more on my perl involvement. I've done the Debian-without-perl dance - that's what Emdebian Crush is. It can be done but it has *nothing* to do with standard Debian. Changes for that specific situation have no place in the main Debian archive. That's why Emdebian Crush is so out of date - it is (and was always going to be) incompatible with standard Debian and, as such, bit rots very, very easily. I knew that in advance, but I did it anyway and kept the changes out of mainstream Debian. I could have uploaded my qof package to be able to work with busybox instead of coreutils, to not require perl at installation time and the rest of it. I inevitably cross-built that package many dozens of times. I fully understand the appeal of testing a forked build with a package you know very well. I still have those changes in VCS somewhere but there's no way anyone will get me to upload a qof package to Debian which implements them and I would RM any such package myself. > is not installable, in order to test my fixes to dietlibc and klibc > on them. Yes, these are Debian-Ports architectures which I guess you, > in the best case, don’t care about, and in the worst case, to cite > another RT member, don’t want to see any “more Debian-Ports spam”. I'm not a member of the release team but I do try to be reasonably active with RC bugs and related issues during release freezes. This is typically because I have a large amount of work to do on Emdebian which relies on the Debian freeze being relatively smooth. So yes, things like this get in my way and I care about fixing that. In Emdebian, I do care about debian-ports, we support a couple or por t architectures in Emdebian (for now at least, interest does seem to be waning). So I do care about powerpcspe, I did what I could to help armhf and I'll do the same for arm64 but I am getting the message that users don't seem to care about sh*. m68k is completely irrelevant and has been since it was dropped from Debian for not keeping up. Don't assume things about me - I don't hide my involvement in Emdebian and I don't claim to be part of the release team. It shouldn't be too hard to work out what I do in Debian. I am a strong and active supporter of / contributor to debian-ports (and debian-blends and debian-derivatives and i18n and a range of other teams in Debian). I don't hide any of that and I don't deserve to be denigrated by your hasty assumptions. > Maybe this sheds some light on my motivation. Sadly not because I believe you are letting your personal preferences blind you to the wider requirements and benefits of working within Debian. I did a huge amount of stuff for Emdebian Crush which I would never dream of inflicting on standard Debian. There are times and places for personal preferences: limited usage builds and forks. m68k is clearly your pet project but it has NO relevance to Debian and I say that as someone with a clear and unequivocal commitment to the current set of Debian ports and as an Emdebian developer who's even had some m68k hardware once upon a time. Seriously, m68k is not relevant. Move it into a side tree, do the same as I did for Emdebian Crush on ARMv4 and push the changes aside. If you really want to predicate all your work on the requirements of m68k then fork Debian and just work on m68k. Otherwise, forget m68k and get with the rest of the project. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgp3HtU6kONAG.pgp
Description: PGP signature
