[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] gcc egcs to compile ttydev?



On Tue, May 18, 1999 at 06:03:29PM +0300, Juhani Sivusalo wrote:
> 
> Guido Flohr wrote:
> 
> > On Sat, May 15, 1999 at 12:23:51AM +0000, kellis wrote:
> > > rpm, missing too many things and libs.
> >
> > No. ;-)
> > I've got it working here.  Will release in the near future.
> 
> That is good news! Will it be fully working package or just
> extracting capabilities?

Uhm, rpm has about a zillion command line options.  I haven't tested them
all but I haven't encountered a single one that didn't work.  Things that
definitely work are 

	rpm -ivh foobar.rpm
	rpm -qf /etc/what/the/hell/is/that
	rpm -ba foobar.spec
	rpm -e get_rid_of_it
	... the basic stuff

Unfortunately I haven't got my networking set up correctly so I couldn't
test installing packages from the net.  But I don't expect difficulties
there.

A couple of aesthetic questions remain: On RHL all rpm source stuff goes
into /usr/src/redhat.  Would anybody feel offended to use the same path
for MiNT (just for simplicity and for lack of a "standard" distribution)?

What should be the name of our system? Actually something like
"lynx-2.8.1-5.i386.rpm" would translate into "lynx-2.8.1-5.m68k.rpm" but
this is likely to conflict with binary packages for m68k-linux.  Is
"lynx-2.8.1-5.m68kmint.rpm" ok?

Maybe a dream, but ... There is no really big distributor for MiNT.  What
about a MiNT distribution "made by Internet"?  What I think of is a medium
size team with one standard ftp server that maintains all basic packages
needed to run a MiNT system.  It would then be possible to make particular
persons responsible for the maintainance of certain packages.  Now, when
for example there appears a new version of the GNU fileutils, it would be
this person's job to build the source and binary package and to upload it
to the MiNT ftp server.  Without such a common agreement on what the
"official" version of a certain package is it would be impossible to take
advantage of the package revision scheme that rpm provides.

I think, that the active members of this list would already make up a
competent and reliable staff for such a group.

In the future it would maybe be possible to make a comfortable
installation package part of the project but for now it would already be a
big progress if you wouldn't have to grab updates for particular packages
from here and there but could simply connect to one server or one of its
mirrors to keep your system up-to-date.

BTW, for those of you that don't know RPM: RPM is the "Redhat Package
Manager" used by the Redhat Linux distribution.  Provided that the
packages are maintained properly all you have to do to install for example
a recent version of the lynx web browser would be

	rpm -ivh lynx-2.8.1-5.m68kmint.rpm

or even simpler with

	rpm -ivh ftp://ftp.mint.org/lynx-2.8.1-5.m68kmint.rpm

You don't have to read complicated installation guides and the
installation process will also fail if other packages that are required by
a certain software are not installed.  In the particular case of lynx it
would e.g. be possible that rpm will tell you that it can't install lynx
because you haven't installed MiNTNet.  Other advantages are that you can
easily uninstall packages you don't want any longer, it also allows to
apply necessary patches if you decide to build from the sources and (very
practical) you can inquire the name of a package that installed a file you
can't identify ("rpm -qf /etc/resolv.conf" will tell you that
"resolv.conf" was installed by the MiNTNet package).

But this will only work if we sort of centralize things and if we also
agree about some standard directory structure.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de