Re: What happened to libreoffice-common in archive?
On 10/11/17, Vincent Lefevre <vincent@vinc17.net> wrote:
> How can the following be possible?
>
> Note that I have not changed the mirror, and "apt update" does not
> give any error.
>
> cventin:~> apt-show-versions -a libreoffice-common
> libreoffice-common:all 1:5.4.2-1 install ok installed
> libreoffice-common:all 1:5.2.7-1 stable ftp.fr.debian.org
> No stable-updates version
> libreoffice-common:all 1:5.4.1-1 testing ftp.fr.debian.org
> No unstable version
> No experimental version
> libreoffice-common:all 1:5.4.2-1 newer than version in archive
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Why "No unstable version" while
>
> https://packages.debian.org/sid/libreoffice-common
>
> says "libreoffice-common (1:5.4.2-1)"?
>
> Is this a bug with the mirror?
Hi.. I had a (cognitively based) hard time understanding all this a
while back. Still kind of do (not fully grasp) primarily because I
haven't tracked down where to find the notes that hint at the "why".
The packages not showing are possibly sitting waiting, and in fact
this thread exists because you found that out. It has something to do
with Developers' design for *LOGICAL* reasons known to them.
It used to be that I would cherry pick my upgrades via "apt-get
install" after running "apt-get update"... because I'm on dialup
Internet access. I had to go that route to be able to upgrade AND stay
active doing poverty related advocacy shtuff, etc, online.
In going that route, I would install EVERYTHING while not knowing that
some things should NOT be upgraded even though a package does, yes,
sit ready in repositories.
I filed a couple bugs back when because trying to install some of
those packages led to "apt-get" UNINSTALLING other *critical*
packages, sometimes over 100 at a time. As it turned out, THAT kind of
thing is why those packages are on hold...
And I guess that's why they're showing up the way they do in your
"apt-show-versions" query feedback there. I'm using Buster/Testing,
and libreoffice-common is on hold... and has been on hold A VERY LONG
TIME. If I do "apt-get upgrade, I see something like this:
.......
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
[list of ~140 well-known package names (including everything
libreoffice, cpp-6, cpp-7, yada]
.......
NO complaints on packages of that size being held back, have I
mentioned dialup, yada-yada. *grin*
If you already do the following, then this is just noise, but I now go
the "apt-get upgrade" route after updating my apt.
In my special use case, I still "apt-get install" cherry pick after
the readout from the pending upgrade. The difference now is I cherry
pick from what UPGRADE would do versus where I used to pick from all
things shown by "apt-show-versions upgrade".
Oh, you know what, as I write that, I'm realizing that it sounds like
you're seeing what I could have used back then. It sounds like
apt-show-versions isn't reporting something that is in fact on hold.
*COOL!* If that used to exist even way back way, then I just wasn't
using the right flag to see that output or something.
Two things I scratch my head over are:
#1 Why do those packages show up at all, even though it's as being
"held back"? For now, I *a-sume* it's so that it's public knowledge
that there is the possibility for an upgrade if you just absolutely
must do so.
Knowing those packages are on hold is your sign to absolutely proceed
with caution, nay, just don't even go there. Although.... I
encountered something myself last night for the first time where it
wants me to upgrade some of developer packages. I may just do it since
it's because something else is not working right now anyway. Let's go
for total broke. *grin*
#2 WHY doesn't "apt-get install" balk when we try to manually install
those packages that on hold? I just quick tested, and it still
doesn't.
My rather unhumble is that apt-get should balk (not unlike
apt-show-versions there). It seems that apt-get should stop us and ask
us ARE WE SURE then specifically state that those packages have been
put on hold for intellectual reasons known to skilled Debian
Developers. After that, we can make an informed executive decision
regarding going ahead or canning the attempt for the time being..
Anyone have any feedback on what any other package managers do with
packages that are on hold? It would be about being a *VERY* newbie
friendly feature to at least warn before proceeding on.......
Cindy :)
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with... pumpkin spice cookies and a slushing cup of (cold) coffee *
Reply to: