Re: Diety UI draft
Bill Mitchell wrote:
>
> Hmmmmm.... A package which is installed on the user's system but
> which is not mentioned in a Packages file as either available
> or replaced is deprecated, right? It was once available, or
> it wouldn't be installed. It's now not available, or it would
> be listed. It hasn't been replaced, or that would be seen in the
> Package file(s). If the package is neither installed nor mentioned,
> it is simply unavailable. It may be deprecated, but there's no
> way to see that.
This is a very good sum up of the problem, thanks.
It may not be depricated, true, but I maintain that under these
circumstances, it is very likely that it has been depricated.
The only other way is an explicit deprication system. The only
problem being that it may get out of sync with the Packages file.
This is a minor problem however.
> (This is complicated by having several Packages files. A package
> which had moved from main to non-free would not be deprecated if
> the Packages file from non-free is being considered, but would
> be deprecated if the non-free Packages file is not being considered.
> In either case, it might be obsoleted by a package in non-us if the
> non-us Packages file is being considered.)
Precisely. It is a sticky issue.
> (actually, "replaces" in english is expressed by "Conflicts
> _and_ Replaces" in package control files, or so I understand it.
> "Replaces: x" in the control file of package y does not mean that
> y replaces x unless y also says "Conflicts: x".)
Again, true. I should have been more explicit.
Manoj Srivastava wrote:
>
> Don't forget packages that have not made it into the Packages
> list yet (for completeness only, I don't think there would be too
> many people in these straits, and those that are can ignore the
> deprecatedness of the packages)
I mentioned this in one of my examples. As you say though, this isn't
a very likely case. (It will happen, just not often, and probably only
to those people that install from Incoming in wihch case they are
probably capable of dealing with this hiccough).
Martin Alonso Soto Jacome wrote:
>
> And how about commercial or any other kind of third party packages that are
> simply not part of the distribution at all? Listing them as deprecated is,
> IMO, too strong, as they don't appear in any packages file but may be
> completely up to date.
This will only be a problem if a company starts to distribute deb packages
or if people instal an rpm with alien. If an installer from contrib/non-free
is used or if the package is installed outside of the debian packaging
system, there will be no problem.
Manoj Srivastava wrote:
>
> Maybe it is time to use a separate mechanism for obsolete and
> deprecated packages? Like a hand-crafted Packages file that contains
> the keywords thet Deity can look at to determine this?
I'm not against this proposal. Adding the keywords "depricated" and/or
"obsolete" to a package's "Keywords:" header in the Packages file
would be a much better solution. I just didn't figure it was universal
enough. i.e. I figured it would be too manual and/or error prone.
> I don't think there is a whole lot of obsolete/deprecated
> packages generated out there, so maintenance would not be very
> onerous, and the (deficient) heuristics for determining obsolescence
> may be shelved.
If this could be kept up-to-date adequately, and people would prefer it,
I have no problems of using it instead of the proposed heuristic.
We could always allow the heuristic as a user option (normally turned
off).
Thanks,
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: