YAPIB (was: Drawing graphics on terminal)

[Paul Robinson]

On Fri, Jun 20, 2003 at 10:37:58AM -0700, Tim Kientzle wrote:

> Yes, meanwhile, the server providing B times out your connection,
> the whole install gets rolled back, and you have to start again
> from scratch.  Not pretty.

Quite. Unless you ship all dependancies as part of the package in the same 
file, which kind of defeats the object of having packages.
 
> Hmmm..  There are two problems here:  The first is maintenance.  Suppose
> a couple of friends of mine set up a site with packages that they're
> building.  I want to be able to add their site to my personal list of
> package sources without having to go bug the "Official FreeBSD FTP Package
> Uber-Person" to get their packages added to the master file.  This
> means that my pkg_add needs to be able to search multiple sites no
> matter what.

Fair enough. So, if I state "pkg_add -r apache" it's going to grab the file 
from the main site, or the local DB for apache. If I were to specify 
"pkg_add -r ftp://some.site.somewhere.com/~myfriend/pkgs/apache.tar.bz2" or 
whatever, then obviously I'm not going to look at the local DB for apache, 
or try and get the re-direct file off of the FreeBSD server - I'm going 
straight for the pkg I've specified.
 
> Don't rely on a single definitive source of package information.
> Having some sort of redirect support in the INDEX file is fine
> and easy to add, but you still need the client to be able to search
> multiple sources.  This is one thing the Debian folks got right.

I think what I'm talking about allows for that. It allows for a big local 
database, a remote database maintained by FBSD folks, a smaller footprint 
than the current packages take AND allows for installs of remote or local 
packages that are not part of that schema. In addition, it'll also try and 
build the port if it can't find the pkg.
 
> The other problem is that the current -r is fundamentally limited
> (to a single network source) and draws a rather pointless distinction
> (you get to search either disk sources with PKG_PATH _OR_ you get
> to search a network source, but not both).  I'd like to erase that
> distinction so that pkg_add just searches all available sources.

That's what I'm saying. -r no longer grabs the package from the remote 
server, it grabs a file from the remote server that tells you where the 
packages may be, and failing that, what the port is. Equally, without -r it 
searches the local database, unless I specifically name a file in the form 
ftp://blah.com/package.tar.bz2 or ~/mypackage.tar.bz2 or whatever, but if I 
just "pkg_add apache" it'll search local DBs in the form similar to my last 
e-mail.
 
> Easy to do, but I'd be cautious with this.  Building OpenOffice or KDE from
> ports is an adventure that most people would rather skip, and pkg_add 
> shouldn't
> be automatically starting a port compile just because it notices that 
> there's
> a 1.0.3 port and a 1.0.2 package.

Yup. But we can alter the files for those special cases where we know a port 
takes 14 hours to build, 2Gb of disk space and 512Mb RAM, and say "are you 
REALLY sure you want to do this?".

Besides, as far as the example with the plane is concerned, within 6 months, 
we'll all have 10Mb/sec to our seats, surely? :-)
 
> Of course, there's also some merit to working on this issue from
> the other side.  In many cases, port requirements could easily be
> satisfied from packages.  (How many people really need to compile
> the JPEG library?)

Sam Smith e-mailed me over the weekend with a patch he made to the OpenBSD 
ports where you could specify FROM_PACKAGES or FROM_SOURCE either on the 
command line with make, or in the conf file and then ports kind of does what 
we're talking about. So, if by default you have in mk.conf (or whatever it 
is, memory is poor on Monday mornings) you have FROM_PACKAGES=yes when you 
do "cd /usr/ports/graphics/jpeg; make install" it tries to find a package 
before it builds the source. This is sensible.
 
> All of this already exists.  Ports already register with the /var/db/pkg
> DB and the ports framework already has make targets to build packages
> from any port.

Yeah, I'd forgotten about the "package" command on ports. Never used it, but 
kind of remembered from the man page, which I've just refreshed my memory 
of. Because of this though, there is no excuse for a port to be ahead of a 
package. It wouldn't take much to cvs the ports collection on a daily basis, 
track those ports that are added or updated and automatically build a 
package.
 
> This already exists; it's called /usr/ports.  See the pkg-* files,
> the Makefile, etc.  Those already exist, and can be mined by other
> tools.  (Look at crunchgen for some tips on how to effectively mine
> data from conforming Makefiles.)

No, no, no, no. ports is not what I'm talking about. I know it seems daft, 
but I think I've lost you somewhere here. Maybe I can get what I want from 
taking Sam's patch and adapting it for FreeBSD, but it's still not quite 
what I'm talking about.

Let me do some work, and then during the week I'll send you some design docs 
off-list, and maybe that'll explain...

-- 
Paul Robinson