Re: gdselect alpha 3
On Thu, Oct 15, 1998 at 05:52:59PM -0600, Jason Gunthorpe wrote:
>
> Hmm, I think this is my first comment on this..
>
> On Thu, 15 Oct 1998, Tom Lees wrote:
>
> > On Wed, Oct 14, 1998 at 02:29:04PM -0700, Joey Hess wrote:
> > > Are there any plans to merge this with apt? Seems gdselect has the frontend,
> > > and apt has the backend.
> >
> > Well, I could do with some apt in-built dependency handling :) There isnt
> > time before the freeze, and AFAIK there are no plans now (which means
> > there are no plans now).
>
> I think this idea of 'lets quickly do something fast' is ill concieved and
> is ultimately going to hurt our image. I've looked at the latest version,
> it looks rather pretty, it's slightly more functional than dselect but
> that's about it.. It doesn't support any of the more sophisticated things
> that people are clamoring for, and it requires X, GTK and a wack of ram.
But, it does answer an immediate need... dselect is now too unwieldy
to use with the number of packages we have... apt is not ready.
Compare it with the package pre-selections in hamm. They were "quick
and dirty", but they worked, and I believe they helped a lot of
users in installation (they were useful last time I used them).
The only idea is not "lets quickly do something fast". I started playing
around with a simple "package browser" about a month ago... that's where
the base came from. Converting it into a fully-blown package selector
is what I decided to do.
> The fact that it doesn't use the APT library only makes things worse as
> now it could have big bugs in odd places!
^^^^^^^^^^
Probably does have... but then APT isnt perfect either. I think the point
is APT has had much more debugging, this hasn't.
I agree, but I needed something to get it up off the ground quickly.
It could now almost certainly be ported to libapt very quickly,
whereas writing it to libapt in the first place would have been
harder, especially considering I already had the basics done a while
ago.
> > Only problem is, apt is in C++, this is in C...
>
> So compile your code as C++, it's not hard, change the gcc call to g++ and
> rename the source files. Then you have to fix up a couple casts and some
> other things and presto, it's C++. You don't need to use gtk-- or anything
> else like that.
Oh. In that case, I will redirect my efforts to this.
> > Everything else is done, and I'm adding more UI features.
>
> In alpha3? Quick IRC survey shows that it locked one persons machine hard,
> takes huge amounts of ram+time and has randomly segfaulted for another...
AFAIK, UI features aren't what cause these - its my q+d package "lib".
The UI features are very quick, IMHO cleanly coded, and I thought them
out a lot. I also need to run it through a malloc debugger soon to
check out some possible memory leaks/boundary probs.
> I belive Adam Heath has been investigating porting gdselect to libapt,
> perhaps you should talk to him.
OK, good idea (he's CCd)...
Adam, how far have you got? Maybe we should collaborate on this.
I believe its probably not much effort to port to libapt - the main
problem is the "dependency screen" bit.
--
Tom Lees <tom@lpsg.demon.co.uk> <tom@debian.org> http://www.lpsg.demon.co.uk/
PGP Key: finger tom@master.debian.org, http://www.lpsg.demon.co.uk/pgpkeys.asc.
Reply to: