Manoj Srivastava wrote: > > Hi, > >>"Behan" == Behan Webster <[EMAIL PROTECTED]> writes: > > Behan> btw, just to remind you, in this new interface, there is no > Behan> distinction between remove and purge (I've always found that > Behan> distinction confusing). They are both the same in deity. All > Behan> that happens is that on a remove/purge, the confiles are stored > Behan> in /var/backup/dpkg/<package> and if the package is ever > Behan> reinstalled, the old conf files can be recovered from there. > > I think that this may be going beyond Deities domain a > bit. Deosn't dpkg diffretiate between the two? Since there is a > difference in the underlying mechanism, I think it is wrong for a > user interface to remove it in the name of simplicity (I hate > microsoft).
This has nothing to do with Microsoft. It has to do with UI design. Designing a UI for an existing process means you will have a terrible UI. dselect The idea is to design functionality and then implement the bits underneath. Although dpkg is what will be the underlying mechanism for the first version of deity, we should not be limited to just that. This is an interim release, and no more. Designing a good GUI for a command-line program is impossible. You will only have a mediocre GUI at best. Command-line actions and GUI actions do not match up well becuase they are based on two different user mental models. Again, dselect should be more than enough proof of this assertion. I am removing nothing from dpkg for the sake of simplicity. What I am doing is a technical design of a GUI. Dpkg has added functionality in it for the dselect GUI. I am suggesting nothing less, than added functionality to support the deity GUI. In this case, the interface does not need to differentiate between two alternatives which dselect had to do before. The only difference is whether conf files are kept around. I am suggesting they always should be. The only difference being that they are kept in an out of the way place (/var/backups). In this way you actually simplify how much the user needs to figure out. Is that not what a GUI is for? I'm afraid I resent the reference to what I'm doing is the same as Microsoft. I hope I am misreading the intent of your comment. > If you think that this is wrong, then this should be brought > to the light of day, possibly on debian-devel, or in a mail message > to the dpkg-maintainers, bruce, and a few others (I prefer > debian-devel). I have brought this to light of day. Just not on as open a forum as debian-devel. I'm afraid I don't find debian-devel condusive to the design process. There is too much noise, and not enough substance. It is fine once you have a design to review, but design by commitee does not yield a very good design. Brain storming on debian-devel the other hand (which is how we started this design) is/was very useful. Just explaining the first version of my design was very hard (and extremely frustrating). I don't know how many times people asked if deity included some feature, or that it should do something some way, and all I did was point them to the URL where that was covered. Of course there were several individuals who rightly pointed out faults and corrections. (I was glad a few people actually read my design!). *sigh* Ok, now that I've vented my frustration... 8) If you think this is necessary, so be it. I thought those involved were reading this anyways, and now that the list is digested, it's all public record anyways. Not to mention, because of the way the first version is being written (a wrapper to dpkg) we have to talk to the dpkg people anyways. After all they will be the ones implementing it. > Behan> Now since we seem to first be building a wrapper around the > Behan> current dpkg, I suggest these changes be requested of dpkg, but > Behan> I still think that deity should work towards a common backend > Behan> library that handles all things and deity and dpkg be simply > Behan> possible front ends to this library. > > Hmmm. In that case, again, I thnk the design should be opened > a bit more, at least the current dpkg designers should be included in > this group. Has nobody mentioned this ultimate merger to the dpkg people yet? I expect that they won't really want to merge until they see more of the benefits of Deity, but we can at least start to try and sell the idea to them. > Behan> I like dpkg as a command line tool, but as the backend to a > Behan> more complicated GUI (in design, not useability), dpkg stinks! > Behan> Building special GUI support funcions into a command-line tool > Behan> is rediculous. Although for the first version it seems that is > Behan> what we are faced with. > > Yesss, I think so. Actually, I think if we are going to go > beyond a interface, into redesign of things, people should be > forewarned (or else there is likely to be a firestorm when we unveil > this. ) I have never said anything other than deity and dpkg should ultimately be merged. I have said so on debian-devel and in private mail to many people (not that I'm implying that you should have read this private mail, but simply that I have said this same thing to many people). I agree that people will be uncomfortable with this idea (as we've seen in the past). I think it will become more palitable once they see the advantages such a merger will entail. > We tried initially to make Deity into a full fledged package > management system, and were told to limit ourselves to a user > interface module (if I recall the evnets clearly). I think we should > not go beyond without notifying other people. The entire deity design requires many changes to dpkg. All of them are additions though. My point is that the appropriate people indeed need to be talked too. Afterall, I'm sure they will be the ones that will be doing the changes. I think it was suggested that we concentrate on the UI for now, but no one has ever said "dpkg is sacred and shalt not be changed by the deity project". The goal of the first version of deity and the ultimate goal of deity are two seperate things. Of course, this is my understanding of how things stand in the deity project. > On the gripping hand, though, I am the newest member of the > team, and may be getting to big for my britches. If ia have > misunderstood the tenor of your message, please feel free to put me > in my place ;-). Well I for one plan not to put anyone in their places. We're all on the same side here, we just have different opinions. There are no junior members of this team as far as I am concerned. Later, Behan -- Behan Webster mailto:[EMAIL PROTECTED] +1-613-224-7547 http://www.verisim.com/
