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

Re: New package managment (fbsd ports)




On 30-Sep-99 Ingo Ruhnke wrote:
> Erik <br0ke@math.smsu.edu> writes:
> 
>> wget is impressive, but not omnipresent just yet. But it's very
>> small, so I wouldn't be opposed to having that handle downloading
>> packages.
> 
> Falling back to lynx or ftp is allways a good idea.
>  
>> If anyone is versed in freebsd, please feel totally free to correct
>> or comment.  I'm just beginning with fbsd, and trying to get my feet
>> under me. I'm sure there are inside tricks that I d'no and stuff :)
>> When I learn more, I'll open my big fat mouth again and bore
>> everyone :)
> 
> IMHO the ports system would be the wrong direction to go in this case,
> what is needed is something simple, but the ports system is AFAIK more
> like a normal package management (deb/rpm), not a simple download
> helper, far to much overkill.
> 

the ports schema is very simple. It's almost exactly what's been discussed as
far as I can tell :) either I'm mistaken about what was discussed, or you're
mistaken about ports. 

To implement download helpers, we need to know what dependancies have to be
downloaded. The easiest fastest way to do this is to have packages register
into a database and then the auto-loader queries that database. That's how
debian does it, that's how redhat does it, that's how fbsd does it, the only
alternative I can see is to attempt to compile and if it fails on that package,
assume the package isn't installed.

A ports makefile just contains what the package is, what it depends on, where
to get it, and anything special (for packages that don't compile out of the
box), and a convenient .include for all the behind-the-scenes stuff.

The ports maintainer makes a makefile, an md5 file, and a couple small
description files (a one-liner and a breif synopsis). They also slap together
any patches needed to make it compile out of the box. That's very simple for
the maintainer.

The end user cd's into the right directory, and types "make install" and that's
it. If they want it gone, it's "make deinstall". "make fetch" just downloads
the file. "make" will fetch and compile, but not install/register. 99% of what
"normal" people will do is "make install" and "make deinstall". I think that's 
a lot simpler than "./blah.sh && ./configure <parms> && make all install" for
the end user? 

> -- 
>                                   http://dark.x.dtu.dk/~grumbel/pingus/ | 
> Ingo Ruhnke <grumbel@gmx.de>             http://home.pages.de/~grumbel/ |
> ------------------------------------------------------------------------+
> 

        -Erik <br0ke@math.smsu.edu> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.