Bug#705550: PTS: provide more accessible package description
On Wed, Apr 17, 2013 at 1:14 AM, Antoine Beaupré wrote:
> On 2013-04-16, Paul Wise wrote:
>> On Tue, Apr 16, 2013 at 11:49 PM, Antoine Beaupré wrote:
>>> I almost made this bug report just asking for the package
>>> description on top before remembering that was not possible
>> We could actually do that for single-binary source packages - just
>> take the description from the unstable version of the single binary
> That would be pretty cool.
Added, until the next cron job, you can see that in action on these two pages:
It is based on two heuristics:
If there is only one binary package, the source package gets the same
If there is a binary package with the same name as the source package,
the source package gets the same description as it.
If you have any ideas for more heuristics, please let me know.
Here are a couple from IRC, thoughts?
<themill> source package foo has binary package libfooX?
<pabs> hmm, I wonder which of libfooX or libfoo-dev is generally the
<themill> pruning off " - .+" at the end of the description when
there's more than one binary package?
> Make it visible more clearly, maybe a <small> line below the link?
Hmm, I think for source packages with lots of binary packages this
could be problematic. I've implemented a compromise, if there are less
than 5 binary packages then the descriptions get shown, examples until
the cron job runs:
> Way I see it, this could be smack in the middle of the page, either on
> top (if we really want to make this a homepage) or at the bottom (if we
> want to keep the PTS dev-specific) of the middle pane.
Hmm, I think this is a bit more problematic, the PTS is already pretty
>> That could be done by my suggestion above of turning the binary
>> package links into links to the sid/unstable (or whatever dist they
>> are available in) page for the binary package. Would that do the
> Yes, that would!
Implemented, with priority unstable experimental testing stable
oldstable, examples until the cron job runs:
> Yeah well I guess this is where I beg to differ. :) I don't like to have
> those artificial limits. While the output of the PTS looks really
> technical, and I am fine with that, a little nudge would make it useful
> for a wider range of users.
Hmm ok. I'm fine with any changes as long as they don't make the PTS
less useful for what I consider the primary audience -
maintainers/uploaders/NMUers/sponsors of the source packages shown.
> For example, my use case is for technical documentation, where as a
> system administrator I want to have an HTTP link to a "debian
> package". Linking to the p.d.o page in sid /could/ work, but will break
> once it is removed from sid (if ever) for example, while the PTS page
> sticks around. Also, as you said, the p.d.o is for "users" (I am
> thinking of a desktop user here), not "administrators" (like me,
> regardless of the fact that I'm also a DD).
I generally class "administrators" as "users" too.
> I find the PTS page useful for much more than "developers" - it is very
> useful to have a quick overview of all the versions of the package in
> backports, sid, etc, the number of bugs opened, if a new upstream
> version is available, who to contact for problems, etc. This is all
> stuff that sysadmins use and need on a regular basis in dealing with
> debian packages as "products", and i find the PTS especially useful for