Re: Diety UI draft
Raul Miller wrote:
>
> Behan Webster <behanw@verisim.com> wrote:
> > The problem being that I'm not sure how we could tell the difference.
> >
> > The only way I can think of detecting a depricated package is that
> > if a package maintainer re-uploads the depricated package with
> > "depricated" in it's keyword list. Do maintainers really want to
> > do that?
> >
> > Do you have any other ideas?
>
> The presence, in a packages file, of either a newer version of
> the package or a package which superceeds the package should be
> required before a package may be considered obsolete.
How about the case of a package being dropped from the distribution?
By your method, the package will never be marked obsolete even though
(at least in my book) it has been obsoleted.
To pick a nit, I don't think marking a package obsolete if there is
a newer version is particularly useful. Having a newer version of
a package is usually considered an upgrade, isn't it? Or perhaps
that's not what you meant above.
I believe there is a difference between a package being obsolete and
a package being replaced. This difference is made in the current
design.
But like I said, the absolute worst that can happen is that a package
can be mistakenly shown to be obsolete (no other action taken, except
looking for a replacement package). Is that so terrible?
The only time I can ever imagine packages to be mistakenly shown to
be obsolete is if you alternate between 2 very limited source lists
that (somehow) have very little overlap in packages instead of a
larger superset of the two. I'm not sure why someone would want to
do such.
Does that cover your concern adequately?
Behan
--
Behan Webster mailto:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: