Future owners/ACL choices
Ville Skyttä
ville.skytta at iki.fi
Mon Feb 26 20:39:29 UTC 2007
On Monday 26 February 2007, Michael Schwendt wrote:
> On Mon, 26 Feb 2007 11:00:43 -0700, Kevin Fenzi wrote:
> > Yeah, there needs to be periodic 'culling' of the orphans.
> > If they haven't been picked up in a while (how long?) they should get:
> >
> > - removed from the repository (all branches?)
>
> Of course! All branches! Else it creates broken upgrades and bug reports
> that go to "orphan owner".
That's only a partial solution, it won't help people who installed it while it
was available which is very confusing. IMO that'd make it a no go; instead
either
1) Never remove orphaned packages from non-devel distros only because they're
orphaned, and do document whatever there is to document about them in the
next release notes (at least a list with a caveat that it is possible that
some of them will reappear later and thus the accuracy of the information is
likely to decrease as time passes from the release date), or
2) Arrange a way to have the orphaned packages removed or at least suggested
to be removed from end user systems at the time they disappear from
repositories. Far from nice in the first place, and possibly a PITA if one
has local/3rd party packages that have dependencies to removed stuff.
> > Of course it's possible that removing an orphan will break a non orphan
> > package, so what do we do there? Let it be broken and the maintainer
> > can bring the orphan back if they want?
>
> Is that a problem? Removing the orphans would create a broken deps report
> in that case and mail all package owners that depend on the orphan. If it
> happens early enough, there should be plenty of time to find a new owner
> and rebuild the package.
This is certainly not something I'd like to see in non-devel distros,
especially if the mindset for fixing the resulting broken dep chains is that
there's "plenty of time" to do it. But perhaps that's not what you meant for
non-devel distros?
More information about the Fedora-maintainers
mailing list