Re: SEUL: Common SEUL/e-linux tools needed

[lso8219@cs.rit.edu (Loren S Osborn)]

> When I was reffering to self contained packages I think it is OK to ignore
> libraries which are a must for all basic linux systems nowadays like libc 5
> (or glibc whenever this project will become available) these will be
> installed in the base system.

So you think packages that use non-essential packages like xforms, Qt,
GTK, povray, pstools, etc. should lug them all around with them...???

I don't see what's wron with popping up a dialog that says:

	The foo program requires that you have the following
	programs installed:
		a-bar
		b-bar
	and a newer version of:
		c-bar
	You may...

	<Search for packages locally> <Download them> <Cancel>

I think what RPM's GUI front end does ( no indicator... just doesn't do
anything, and doesn't tell you why...) is just plain bad...


> As for compatibility, With existing package formats, I also believe there
> are allready too many formats. Maybe the best choise will be to make the
> 'installation wizard' use actual files in tar.gz format.(which as far as I
> know is the only format not flavor dependent in Linux) thus an advanced user
> may choose to open and install the package manually.

The problem with existing formats is that they don't contain enough
information to (pardon the expression) "dumb-down" these packages to GUI
configuration... the only way we can get around this is to require a certain
type of package... If we go with RPM, it will *STILL* be a sub-set of RPMs
that will be usefull to us...  Honestly, I think that once we have a running
system with the GUI configuration, and people see how great it is, developers
will start supporting us... We may only need to convert, say, a couple
hundred packages ourselves... alot of work, but what we're trying to do (if
we tried to automate the process) would be like attempting to generate a
man page from program source code... concieviable, but I don't think that the
AI is going to be around for another 5 years to do it...

> - size overhead by the way is smaller then the numbers posted since
> packaging will include compression.

bogus argument... all packages are compressed... it's stupid NOT to
compress them... you're not going to cut anything down by more than
half with loss-less compression, and lossy compression is only usable
with *DATA* not with *PROGRAMS*... (maybe you could lossily compress the
comments within the source-code, but what's the point? :)
 
> anyhow, I dont think we should worry much about size from the following
> reasons.
> - distribution media will most likely be CDROM

CD-ROMs only hold 650MB... we can't assume everyone has a DVD-ROM drive...

> - If a library is necessary to run some application, the user will have to
> get it anyway if he wants to run the app. I believe the frustration from a
> larger download time is smaller then the frustration resulting from trying
> to find out why the H**K this package doesnt work , reading all the
> associated README files, and locating the necessary package outlet.

*THIS* is the whole *REASON* for dependencies... they tell you what's wrong
and how to fix them... just because RPM's GUI sucks, doesn't mean that it
*HAS TO*...

> >Also, some of these libraries are
> > big...(That's why most are dynamically linked)
> I think dynamic linking has much more benefits then a mere save of disk
> space

Well that, and saving of memory (with multiple running apps using the same 
d-linked library)

Comments? Suggestions?

Loren
> 
>