[csw-maintainers] Inconsistency on package database
bwalton at opencsw.org
Sun Feb 26 18:32:13 CET 2012
Excerpts from Dagobert Michelsen's message of Fri Feb 24 08:52:59 -0500 2012:
> > When packages are stubbed out, the bugs are supposed to be moved
> > to one of the other projects that obsoletes them. Is this not
> > what's happening or am I misunderstanding the problem you've
> > noticed?
> Correct, this is not happening. Please browse on the bugtracker
> directly to samba by visiting https://www.opencsw.org/mantis/ and
> then use the popup to select "samba_common". Then open the search
> filter and set "Hide Status" to "none", then lots of bugs appear
> which I closed yesterday. From your description I would have
> expected that they would have been moved to "samba", as samba_common
> was obsoleted by this one.
Ok, I'm looking into this now. There are some heuristics applied here
to determine where the bugs are moved. I do take into account the
fact that once stub can pull in multiple other new packages.
I don't actually see samba_common* in the catalog currently. Might it
have been removed instead of stubbed out? That would line up with
what I see in the db.
> However, please note that a package may be obsoleted by more than
> one package, so it may be best to just leave the bugs and
> re-register the _stub packages. I tend to leave artifacts in the
> view so they are clearly visible instead of applying different
> levels of magic.
The idea behind the current function is that dropped packages are
hidden from view, leaving the bugs as is. It's a very simple change
if people would like the removal of a package from the catalog to
result in a no-op as far as mantis is concerned though. If we want to
keep stubs in the db instead of moving the bugs to the new packages,
that's a larger change. I don't mind doing this if it's the preferred
In the case of stub handling, I attempt to move bugs to one of the
packages in the dependency list of the stub using the following
1. Remove CSWcommon from the list.
2. Reverse the dependency list to hopefully skim out automatically
added things (CSWcas-*, etc). Some of these auto things could be
moved to step 1.
3. Pick the first package.
I see that there is some potential for more corner case bugs in this
area though, so I'm looking at how to improve it...
If we want to drop some of the rename detection for stub handling,
many things can become simpler. In hindsight, this might be a better
option for the web db...We could note the catalog name change in the
database and preserve the dependencies. The _stub packages could then
be filtered from the 'whole list' view but made available when
clicking through from an individual package.
If that sounds ok, I'll make the required changes. I think it might
also be a good exercise to empty all of the package tables (in my test
db) and start from a clean slate as if the original catalog was
empty. The tables could then be imported to the webdb on
If anyone is putting real effort into making a nice package browser
based on the buildfarm db though, let me know as I'd rather spend
effort on that than polishing this turd if it's going to be
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
More information about the maintainers