Comment 1 for bug 851266

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.