On Mon, 23 Jul 2007 15:52:52 -0700 "Chuan-kai Lin" <cklin@google.com> wrote: > > This is exactly the kind of work I have wanted to do recently but I've > > been held up by bugs in the tools and infrastructure scripts. I would > > love to know how the upgrades have gone - perhaps some stats on a > > DebianWiki page or some indication of how many upgrades broke, how many > > manual changes and fixes were needed etc. > > I have selected 94 packages that I think a useful base system should > contain, and here is the breakdown: > > 44 are current against sid, > 15 have newer versions in sid, but Emdebian patches (other than > against changelog) applies successfully, Interesting. It is important to note that emdebian-changelog.patch will not apply cleanly if the Debian version has changed. I wish there was a way to solve that. I've been wondering about a delta. This would allow us to diff the old changelog against the new, apply emdebian-changelog.patch against the old, add the delta and then create the next emdebian version. It may turn out to be too much work and we simply need to *always* skip emdebian-changelog.patch when emsource detects a new Debian version and recreate our emdebian version string prior to the build. There is code to do this already within emdebian-tools, it just needs testing. I am unsure whether emdebian-changelog.patch would actually contain enough useful data to make it worth inserting old entries - we have SVN to record the history of the patch file itself. > 22 have newer versions in sid, and some Emdebian patches fail to apply, > 12 do not have Emdebian patches in svn, OK, can you give package names for those 34 please? If you get them to build, patches would be appreciated or if you can send your SSH key and preferred username to Wookey before he leaves, you could commit the revised patches yourself, as a branch. > 1 is obsolete (linux-kernel-headers is replaced by linux-libc-dev). Obsolete for sid, probably worth keeping around for now. > Note that some false-positives in the "current" set. For example, > zlib1g counts as "current" only because all its svn Emdebian patches > are empty, and the built packages still contain man pages and > changelogs. That is one of the packages mentioned earlier where it needs an update against the latest emdebian-tools to sort out the patches. I'll try and sort that out today or tomorrow. > > 1. Updating emdebian packages against new Debian releases should be as > > automatic as possible. Changes should be only required rarely. dpkg > > filtering and other methods (like separate translation .deb files) will > > assist in this area in the future, as will other changes within Debian > > itself. > > Are there any ongoing projects toward achieving this goal? There is only the outline support already in emdebian-tools - emsource and empdebuild. > > 3. Previously, all such contributions have been handled by simply > > allowing SVN commit access > > For the moment, I think me posting interdiffs here and you yelling at > me when I do things wrong seems to work for me, and the messages in > the list archives would serve as a guide for perspective developers. (I don't mean to yell). With lots of packages, using a branch in Emdebian SVN is quite useful because it makes it easier for me to test the revisions. > I am not planning to make any built packages public because I am not > building them through the standard procedure. I build Emdebian > packages natively, and I currently find it more convenient to hack > Emdebian tools to use the native toolchain instead of building and > installing an i386 -> i386 cross toolchain. Please let me know what changes are required in emdebian-tools to achieve these native builds because it is something that Emdebian would like to be able to do. > > 6. Real data on how many emdebianised packages can actually be upgraded > > automatically would be very useful. > > See above in the post. Unless there are tools I am not aware of, the > Emdebian-patch-based approach requires human intervention when a new > Debian version changes one of debian/rules, debian/control, and > friends and makes a patch fail to apply. That stage can be improved and automated. Basically, emsource should detect a new upstream version and currently it tries to take the safer route of backing up the current work and unpacking the new. Combined with the --clean option, I am hoping that this would allow patches to be tested in --dry-run mode. However, if Debian changes files in debian/ there is a chance that the emdebian patch will fail to apply. This only increases the need to ensure that our changes are compatible with the upstream and try to get at least some of those changes committed upstream. Dropping manpages and other documentation will remain an issue for now but dpkg filtering should be possible on installation soon and later during dpkg-buildpackage too. Packages should still be patched to avoid generating files that we don't need where possible. What is currently undecided is just how dpkg filtering will be used for emdebian builds but not for Debian builds. Some form of delta handling could be used for debian/control and debian/rules too. This is completely untested but I think that because we have the old Debian source backed up, we have the new Debian source unpacked and we have the current Emdebian patches, we should be able to calculate a patch that takes us from the old source through the new source to the final Emdebian version. e.g. if the Build-Depends line of foo_0-1 was changed in foo_0-1em1 and then foo_0-2 arrives with other changes to Build-Depends, it should be possible to isolate the changes from 0-1 to 0-2 (easy), diff against the changes for 0-1em1 and come up with a patch that goes from 0-2 to 0-2em1 ? Any ideas / solutions gratefully received!! :-) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpdDx8cNhlrQ.pgp
Description: PGP signature