Re: The Deity tree widget
Jason Gunthorpe wrote:
>
> On Tue, 18 Nov 1997, Behan Webster wrote:
>
> > Jason Gunthorpe wrote:
>
> > I'm afraid I don't understand the question. Sorry.
>
> Okay, I'll ask you later when I have something to show..
Sure thing.
> > Yes. If we use the +/- then the dep/whatever icons will go to the right
> > of the +/- just like in the linux Explorer. As you say, what is
> > currently in my web pages is a bit confusing. It was more of an
> > experiment. A failed experiment IMHO.
>
> Are triangles any different, placement wise, then +/- ? (I'm just goint to
> use +/- as a generic term for the icons whatever they end up being.)
Yes, same placement.
> > Identifying new packages shouldn't be a problem. Should it? If you have
> > to add a file to your cache (because it wasn't there on the previous
> > running of deity) surely you can assume it's a new package. Or am I
> > missing something?
>
> Well, to handle removing of versions and other changes the whole cache is
> erased and rebuilt. The new generator is going to have to keep a copy of
> the old one and then rebuilt the new one, cross reference to find new
> packages.
>
> Do new versions get a new mark or only new packages?
New packages get the new mark, new versions get the upgrade mark.
It just occured to me. I've haven't taken into account the case of a
package that has never been installed, but is now visible because of a
change in the keyword list. It would probably be treated just like a
new package only it would have a different icon instead of the new
icon. Perhaps "old" or "not installed"? (Although as an icon, not
words! 8)
> Okay, you tell me then, here are 3 different (cronological) invokations
> of deity:
>
> RIK
> -*- libc 1.0 ^ 1.1
> --* libc 1.0 ^ 1.1
> - libc 1.0
> -?? libc 1.0 ^ 1.1
--* libc 1.0 ^ 1.1
However, I think the following is a better example (IMHO). Again, this
is over several invokations of deity. We'll also assume a rapid
development of libc for this example. 8) Also the first column is what
deity shows orginally, the second is what the user sets it to:
- * libc new 1.0
--* --* libc 1.0 up 1.1
--* -*- libc 1.1 up 1.2
-*- -*- libc 1.1 up 1.3
-*- --* libc 1.1 up 1.4
- - libc 1.4 (note, no new version is available)
--* --* libc 1.4 up 1.5
--* -*- libc 1.5 up 1.6
Does that help?
> Now, a feature seems to be missing, given that deity is supposed to
> automatically select packages for upgrade and install based on other
> selections how can this be prevented on a per-package scale? (Think:
> Package is not installed, user wants to ensure that package is -never-
> installed, ie Bruce might not want to go through his ritualistic cleansing
> again so he would make QT as being uninstallable to ensure it never gets
> installed automatically :| )
Yes, you are correct. This feature does not exist. There is currently
no way to blackball a particular package. I don't think that "holding"
a package so that it never gets installed is a good idea.
The way things currently work, A package is automatically scheduled for
installation even if it's not currently in the visible list (i.e. a
package may be installed by a dependency even if keywords don't put it
in the selection list).
If this is truely a feature that people would like, (i.e. sort of a
package kill list), I'd suggest just that... a package kill list. A
list of package names that you never want installed. I would think that
a list of regex expressions would be best, otherwise a simple name
change would cicumvent a kill request. In the case of qt, it would be a
simle "^qt.*$". But I see this as seperate to the selection list. Most
users won't care about this. I would consider this an advanced feature.
Thanks,
Behan
--
Behan Webster mailto:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
Reply to: