[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Patch: grep 2.5.1.ds2-6em2

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

Attachment: pgpHa0fgRgvRb.pgp
Description: PGP signature

Reply to: