removing superseded packages?

removing superseded packages?

[Robert P. J. Day]

  is there a protocol for suggesting the removal of obsoleted(?)
packages?  i was looking at the recipes for some embedded tools, and
noticed:

$ ls recipes/i2c-tools
files               i2c-tools_3.0.2.bb  picodlp-control_0.1.bb
i2c-tools_3.0.1.bb  picodlp-control     read-edid_1.4.1.bb
$

  in other words, both versions 3.0.1 and 3.0.2 (3.0.2 is current).  a
recursive grep of the entire checkout reveals:

$ grep -r i2c-tools *
conf/checksums.ini:[http://dl.lm-sensors.org/i2c-tools/releases/i2c-tools-3.0.1.tar.bz2]
conf/checksums.ini:[http://dl.lm-sensors.org/i2c-tools/releases/i2c-tools-3.0.2.tar.bz2]
contrib/angstrom/build-feeds.sh:                      i2c-tools \
recipes/tasks/task-cli-tools.bb:  i2c-tools \
recipes/i2c-tools/i2c-tools_3.0.2.bb:SRC_URI =
"http://dl.lm-sensors.org/i2c-tools/releases/i2c-tools-${PV}.tar.bz2 \
recipes/i2c-tools/i2c-tools_3.0.1.bb:SRC_URI =
"http://dl.lm-sensors.org/i2c-tools/releases/i2c-tools-${PV}.tar.bz2"
$

  given the above, it would seem reasonable that version 3.0.1 can be
tossed, no?  unless there's a compelling reason to keep it around.

rday

p.s.  i can submit a patch if that's all it takes.  from what i can
see, that just involves removing that single older .bb file.

--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: removing superseded packages?

[Mike Westerhof]

Robert P. J. Day wrote:
>   is there a protocol for suggesting the removal of obsoleted(?)
> packages?...

Removal of packages has been discussed in the past; it's not as simple
as it seems.
...
>   given the above, it would seem reasonable that version 3.0.1 can be
> tossed, no?  unless there's a compelling reason to keep it around.

It does seem reasonable, and in this case I have no opinion one way or
the other.  However, I want to point out that in the past, it has been
the case where a "dot-dot" version difference has made substantial
problems for one distro or another.

It's my opinion that disk space is cheap, and the cost of parsing a few
extra bb files is not so high that we cannot afford to keep a few
versions about.  There's nothing more frustrating than taking a weekend
set aside for making significant progress on a distro issue, and instead
spending it sorting out what changed that made the distro not build or
not boot, and then struggling to sort out why the new version won't
work, and then the infuriating part is when you decide to just use a
PREFERRED_VERSION so that you can go work on your original issue, only
to discover that path is blocked because somebody decided, for no reason
other than aesthetics, to delete the old version that used to work!

Again, no opinion on this specific package, just a strong opinion
regarding the removal of old versions.

And yes, I'm quite aware that there are others who disagree with my
opinion very strongly as well -- there is unlikely to be agreement on
any protocol or policy for this, I think.

-Mike (mwester)