Re: New package managment

[Erik <br0ke@math.smsu.edu>]

On 26-Sep-99 Pierre Phaneuf wrote:
> Bryan Patrick Coleman wrote:
> 
>> What I have in mind is a kind of supper package class that can do more (more
>> easily) than what is out there. I think I am going to use dpkg & apt as the
>> underlying pakaging system. What I am envisioning is "grouping" several deb
>> pakages into on superfile that can install or build packages as needed.
>> 
>> For example lets look at the Pingus situation. You have this supper package
>> that contains clanlib and hermes libs for Pingus.
>> 
>> When you install the package it sees tha need to install the libs as well
>> and does so.
> 
> Did anybody try the FreeBSD "ports" system? Never did myself, but I was
> told that it was rather brilliant and easy to use.
> 

yes, I dropped fbsd 3.3 on a box at work. The ports system is basically what's
been discussed here. There's a /usr/ports/ heirarchy where all the ports are
mentioned (woohoo, one of those dirs is stuff I wrote) and a couple files,
including a makefile. If you cd into one and 'make', it looks for the version
of the package that the ports bundle was made against (it looks like updating
means getting a full new ports heirarchy), if it has the archive file, it
unpacks it and builds it, else it attempts to download it from listed sites.
Theoretically it's a beautiful idea, and for the most part is seems very neat.
My biggest concern is if someone wants to try my package, it'll first try to
access a shell which was over-run by "31337 hax0r" script kiddies. If they get
the idea that that's what's going on, they can put a trojan into place. The
un-suspecting bsd user then cd's into the package, runs 'make install' and it
downloads the trojan package and merrily installs it, and since installs must
be run as root... This is why I said what I said about security, I'm gonna feel
real bad if these dipshits figure out that they could do this and implement it
before I can hunt down the port maintainer and someone gets screwed up...
fortunantly that's almost impossable because fbsd uses md5sums, so unless they
managed to cook up this package in a way that gave an identical md5sum, I'm
assuming fbsd would halt the install and report the erroneous package? I
haven't actually managed to excersize that possability :) now I got something
to try at work.

The biggest disadvantage that I see is there's no single package upgrades. If
one package changes in debian, you download the new package files (.4 megs?)
and it reflects it in the package database. if fbsd's ports has this
capability, I've not found it yet :)

> Also, the Perl CPAN system also has a few good ideas, like the
> "bundles", kind of meta-packages that are actually empty, but have
> information on what packages to get.
> 

that's how debians 'task' packages work :) they have no real content (some
stuff in /usr/doc I think) but lots of dependancies so you just pick the task
package to get the bundle. the new gnome stuff is done this way in debian from
the gnome mirror sites last I checked

> -- 
> Pierre Phaneuf
> http://ludusdesign.com/
> 

        -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.