From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Bumping packages: some comments/suggestions
Date: Sun, 13 Oct 2013 11:42:46 +0200 [thread overview]
Message-ID: <20131013114246.440c3831@skate> (raw)
Hello Jerzy and Axel,
Recently, both of you have worked on and contributed a number of
patches bumping a significant number of Buildroot packages. This is of
course really great, and I'd like to thank you for those contributions.
That being said, I would have two suggestions:
*) It would be great if you could check that the reverse dependencies
of the package you're bumping still continue to build. For example,
Axel bumped 'ortp', but didn't realize bumping it would break
the linphone and mediastreamer. While we certainly cannot expect
contributors to test package bumps in all possible configurations
(especially for packages having a large number of
reverse dependencies), checking at least a few of them is a good
idea. Also, when bumping from one major release to another (such as
berkeleydb 5.x to berkeleydb 6.x), even more care should be taken.
*) To make this "bumping" effort a bit more systematic, I believe it
would be useful to introduce an infrastructure in Buildroot to
automatically check if upstream has a new package. In many cases,
the upstream site has a directory with all the different versions
of the tarball, so checking if there's a newer one in an automated
way would be possible. If we do this for many packages, then we can
run a script every day, and check if there are new upstream
releases available. Debian has such a mechanism with the 'watch'
mechanism (see https://wiki.debian.org/debian/watch/). Gentoo has
the euscan utility (see https://github.com/iksaif/euscan). It would
be nice having something like this, that we could integrate in the
Buildroot per-package stats at
http://autobuild.buildroot.org/stats/ to get a clear vision of
which packages need to be upgraded. If one of you is interested in
doing this, it'd be great!
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next reply other threads:[~2013-10-13 9:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-13 9:42 Thomas Petazzoni [this message]
2013-10-13 10:44 ` [Buildroot] Bumping packages: some comments/suggestions Axel Lin
2013-10-13 13:42 ` Thomas Petazzoni
2013-10-13 15:01 ` Thomas De Schampheleire
2013-10-13 15:06 ` Thomas Petazzoni
2013-10-13 21:04 ` Jerzy Grzegorek
2013-10-14 7:09 ` Thomas Petazzoni
2013-10-14 7:40 ` Jeremy Rosen
2013-10-14 9:30 ` Thomas Petazzoni
2013-10-14 9:38 ` Jeremy Rosen
2013-10-14 10:02 ` Thomas De Schampheleire
2013-10-14 10:04 ` Thomas Petazzoni
2013-10-14 12:58 ` arnaud aujon
2013-10-14 13:56 ` Thomas Petazzoni
2013-10-14 17:11 ` arnaud aujon
2013-10-14 21:55 ` Arnout Vandecappelle
2013-10-15 7:34 ` Thomas Petazzoni
2013-10-15 19:55 ` Arnout Vandecappelle
2013-10-14 13:45 ` rjbarnet at rockwellcollins.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131013114246.440c3831@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox