Update DSP schema to support fast queries
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
The DSP table and object could provide additional information to allow callsites to know exactly which packages are official in a distribution and what they build.
* published, boolean, default False -- Was the package ever published.
When a package branch is unlinked the row can be deleted if this is False.
This permits users to undo linking mistakes
* deleted, boolean, default False -- was the package deleted from a series
When a package is eventually deleted from a distro, the value is updated to True.
New bugs can be reported against undeleted packages.
Existing bugs for deleted packages can be seen.
* description: A summary built from the built binaries (if they ever were built)
Changed in launchpad: | |
importance: | High → Low |
tags: | removed: disclosure |
Hi William.
I have put some more thought into this issue and I think you can help me understand what we really want to do.
published => packaged:
I think this property is beneficial for many uses in Lp. This attribute should not be setable by users. I want to set packaged to True when DSP.ensure() is called with SPPH. Existing DSP entries are updated to True, new ones are created with True.
deleted:
I think this is harder than I first thought. I believe code currently will not let you report a bug for any package that is not in the current series. I think this is wrong. We want to development and supported series represented. Deleted can only be true when the package was published in obsolete series, but is not packaged in supported and current series. Marking a series as obsolete should cause some DSP deleted properties to become True. If my series status was a mistake and I change it back to supported, the deleted properties must be reset to False. If a future series restores a package, the deleted property must be set back to False. Maybe this is property is lower priority that published. Is reporting a bug or asking a question about a obsolete package a bug concern?
description:
I want to see the binary package names in the description so that users who search on a binary name see in the DSP description. The description would only represent the description from the current series. This may cause some confusion for supported series. I had imagined that when a SPR is built, the DSP table gets updated with the binary names. I do not know how to handle cases like Juju where there will never be built packages to get a description from. Maybe using the mediocre source package description (not the one line summary, but the actual description) would suffice? Maybe this needs a garbo job to keep populated.