Synaptic sometimes lists 'unchanged' in to-do list - confusing

Thank you for bringing this bug to our attention. I'm afraid this bug can't be addressed as part of
this project.

Synaptic is being replaced by AppCentre in 9.10 , Hence not a papercut issue. https://wiki.ubuntu.com/AppCenter
You can add your suggestions in the comments page of the wiki.

A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

For further info about papercuts criteria , pls read >
https://wiki.ubuntu.com/PaperCut

From the wiki > "In Ubuntu 10.04, replace Synaptic, Software Sources, Gdebi, and (if appropriate) Update Manager with an expanded AppCenter."

So Synaptic will still be included in 9.10, meaning this might be considered a 'paper cut'?

I believe the wiki hasnt been updated , Only the Software Sources, Gdebi, and update manager will be replaced in 10.04 .
Synaptic is supposed to be replaced in Karmic.

But even, if not it would be unnecessary in the papercuts project, since the Karmic 100 list is full and this would be considered a papercut only for Karmic +1 cycle, Where either way Synaptic will be replaced.

 Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

The unchanged label (not very logical) is used for packages with available upgrades, but not selected for upgrade. I guess we should not display these at all, as the todo list shouldn't contain packages which should not be acted upon. However if anyone else has a better idea, we could also try changing the label "Unchanged" to something like "Not selected for upgrade", or something like that.

> However if anyone else has a better idea, we could also try changing
> the label "Unchanged" to something like "Not selected for upgrade", or
> something like that.

There is some utility to including these packages, provided that the label is clear. Aptitude also includes such packages in it's preview screen.

> status: Triaged → Incomplete

Although up for discussion on what to do, I don't see how this report is incomplete?

Ok, just checked the short descriptions, and based on that (Incomplete = not reproducible, waiting for response from reported) it's not Incomplete indeed, but in order to start working on this, I need some feedback from someone else (as I have said, I could simply remove the items from Unchanged and mark this as Fixed) and as there is no status called Waiting-for-feedback-on-how-to-properly-fix-this-without-causing-regressions-for-many-people I have set it to Incomplete, as for me that is the only status meaning that someone is missing in this bug for a developer to fix it.

On 16 November 2012 18:05, Robert Roth <email address hidden> wrote:
> and as there is no status
> called Waiting-for-feedback-on-how-to-properly-fix-this-without-causing-
> regressions-for-many-people

Confirmed or triaged is still appropriate for that. The issue itself
is not in doubt and we don't want it to expire just because the
resolution may not be clear.

Anyway, your concern that removing the list may be considered a
regression by some people is justified. Given that, it is an easy
decision to just change the label.

Regards

 status confirmed

> Confirmed or triaged is still appropriate for that. The issue itself
> is not in doubt and we don't want it to expire just because the
> resolution may not be clear.
>
> It would not expire, as I have set myself as assignee, and as long as
there is an assignee set, the bug won't expire.

> Anyway, your concern that removing the list may be considered a
> regression by some people is justified. Given that, it is an easy
> decision to just change the label.
>

Easy decision to change the label, hard decision to find out what to change
it to be informative, concise, and not too technical.
Also note that the summary text ("n packages will be held back and not
upgraded") (below the changes tree) will also need an update (most users
won't know what "held back" means, and it's not correct, as not selecting
an item for upgrade is not the same as holding it back - conceptually ...
although in this case the two are equal). Ideas for these labels are
welcome.
What do you think of Upgradeable in place of Unchanged and "n packages
upgradeable but not upgraded" in the summary?

Regards

On 16 November 2012 20:13, Robert Roth <email address hidden> wrote:
> Easy decision to change the label, hard decision to find out what to change
> it to be informative, concise, and not too technical.

Maybe :-) Let's see what some other programs say…

apt-get: The following packages have been kept back
aptitude: The following packages have been kept back

I'd say that “kept” is the way to go here. However…

> Also note that the summary text ("n packages will be held back and not
> upgraded") (below the changes tree) will also need an update

Looking at the code for this window, it *does* try to distinguish
between kept and held (although the text for “n packages being kept
back” is missing). The quoted text is associated with the held count,
so would make it correct given accurate summary information.

It seems that rpackagelister.cc (getSummary) is no longer
distinguishing between held and kept packages, although it remains
instrumented to do so.

rgchangeswindow.cc still has a “To be kept” in addition to held.

Looks like something has fallen away over time here, and this is something
to look at before fixing the apparent string issues. I am not very
familiar with synaptic, but can take a look later next week when I get
some available time.

> What do you think of Upgradeable in place of Unchanged and "n packages
> upgradeable but not upgraded" in the summary?

As long as you mean, “Upgradeable, kept back” However, to save
on translations, the string “To be kept” (from rgchangeswindow.cc) may be
suitable.

> Maybe :-) Let's see what some other programs say…
>
> apt-get: The following packages have been kept back
> aptitude: The following packages have been kept back
>
> I'd say that “kept” is the way to go here. However…
>
The user part of me: I'd like all my packages "to be kept" after an
operation, except those which are "to be removed".

>
> rgchangeswindow.cc still has a “To be kept” in addition to held.
>
> That's still not a friendly string for me.

> Looks like something has fallen away over time here, and this is something
> to look at before fixing the apparent string issues. I am not very
> familiar with synaptic, but can take a look later next week when I get
> some available time.
>
That would be great!

>
> > What do you think of Upgradeable in place of Unchanged and "n packages
> > upgradeable but not upgraded" in the summary?
>
> As long as you mean, “Upgradeable, kept back” However, to save
> on translations, the string “To be kept” (from rgchangeswindow.cc) may be
> suitable.
>
No, I don't mean "Upgradeable, kept back" by "Upgradeable", as if there are
any packages to be upgraded, there is a "To be upgraded" section, the other
ones, which appear in the category we are discussing about, are the
Upgradeable ones.