Date: Fri, 20 Jun 2003 10:47:30 +0100 From: Paul Robinson <paul@iconoplex.co.uk> To: Tim Kientzle <kientzle@acm.org> Cc: freebsd-hackers@freebsd.org Subject: Re: YAPIB (was: Drawing graphics on terminal) Message-ID: <20030620094730.GP20204@iconoplex.co.uk> In-Reply-To: <3EF20ADE.9000904@acm.org> References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <20030616191852.GA52694@ussenterprise.ufp.org> <20030618100125.GP20204@iconoplex.co.uk> <1055948691.92188.10.camel@beastie.freebsd.local> <20030618154012.GE533@xtanbul> <20030619095739.GC20204@iconoplex.co.uk> <3EF1E7EC.3040908@acm.org> <20030619170742.GO20204@iconoplex.co.uk> <3EF20ADE.9000904@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 19, 2003 at 12:11:26PM -0700, Tim Kientzle wrote: > That would seem to be the hard part. I presume you've > looked at SUSE's YAST, Debian's APT, and other such tools? *nods* - nice basis, but not... well... you know. > What I have now works as follows: > * Start reading the package, extract the packing list, parse it. > * Identify any requirements, recursively install those. > * Continue reading/installing this package. To clarfiy your meaning of recursiveness in this context (I can think of another way of doing it "recursively" and I don't have time to peek at code right now), if I want to install package A which requires B and C, B requires D and E, and D requires F, your installer would go Start A -> I need B -> Start B -> I need D -> Start D -> I need F -> Install F -> Install D -> I need E -> Install E -> Install B -> Install C > This has a big problem with network installs. In particular, > the download gets stalled while the requirements are added. > Over a slow connection, this could leave you with a stalled > TCP connection for hours. Not good. In the chain above, if F isn't available for some reason, you have A, B and D all half installed on your machine waiting for a 32Kb library on an un-mirrored FTP server in bulgaria... hmmm... > One way to address this would be to separate "install-time" > requirements from "run-time" requirements. The ports framework > already has some concept of this (separates "build-time" from > "run-time"), but it doesn't seem quite sufficient. If you need it at run time, surely it make sense to grab it at build time? I'm not sure I can see the benefit of seperating it out - you're just going to create a sense of not knowing whether your application is ready to go or not because it's "installed" but doesn't have the kit it needs around it to make it actually *work*.... hmmmm... > I'm looking at a couple of approaches. One is to eliminate -r and instead > have a simple list of package sources that get inspected. Debian's package > management does something similar to this. For example, you might have > an /etc/pkg.conf that specifies the following sources: > . > /usr/packages/distfiles > /nfs-server/packages/distfiles > ftp://ftp3.freebsd.org/some/path/packages-5.8-release/ > ftp://ftp.joesfreebsdsite.org/some/path/packages-5.8-release/ > cdrom:"FreeBSD 5.8 CDROM #2":/cdrom/packages Yup, that's what I was thinking, but you would have such a file for each package, thereby meaning packages can live all over the place. In addition, you wouldn't need that file on the local machine, and for backward compatability, the -r switch grabs a file with that info off of the mirrors, the same way the actual packages are now. It means that in 3-4 years when people are no longer trying to do package management with the current stuff, the mirrors *could* reclaim some disk space. This is likely to be an issue if we want to try and get as much stuff out there as possible run up as pkg's. > installed. In particular, note that this should allow us to support > the CD-ROMs more efficiently, by locating packages on particular CD-ROMs > and then prompting the user to insert the correct CD. There is a minor issue here, around the way I'm planning on helping out the OEM/release engineering stuff as part of the installer effort, in that the package might not be on "FreeBSD 5.8 CDROM #2" but rather on "Dell OEM FreeBSD 6.2 Disk 1", but that's my problem. The more I think about it, the less of an issue it becomes, as I've just written some code in my head around building the release disks that sorts some of this out, but it's an extra req. > Note that this is simpler than having some form of "master redirect" > file, since each repository only needs to track what it provides, > not what other repositories might offer. Users can mix and match > repositories as needed. I'm thinking about backward compatability on the command line for -r that grabs the "master re-direct" file in the format above.. > No opinion on this one. Perhaps you could formulate a couple of > scenarios in which it would be beneficial to be able to mix and > match these two? Where the port exists, but a pre-built binary isn't available, or where somebody wants easy install with his own configure options. So, in your file above, but where you're explicitly discussing a specific package rather than packages in general, you could have a line, for example: ports:/usr/ports/misc/screen:--prefix=/usr/local with command line switches to force the ports option, pass extra args to configure, etc. This means as and administrator you have one 'place' to look after third-party code, you get the advantage of being able to wrap ports into the /var/db/pkg DB, and if the binaries don't exist you can go back to building from scratch. In fact, with a bit more work, you could write a switch to make a package that can then go onto a mirror with nothing more than a command-line switch, based on the port. It also means that if somebody wants to port their application to FreeBSD and distribute a pre-built binary rather than distribute source, they can locally follow the porter's handbook, build their own port, turn it into a package, and then go out and sell it in stores - i.e. it encourages commercial involvement in FreeBSD which is no bad thing. You also suddenly make pkg_add able to handle not only pre-built binaries but grabs all the effort of the ports guys as well. Anyway, I think we're both talking about the same thing here, except you're thinking of a main pkg.conf file, whereas I'm thinking of a DB on disk, or retrieved over the network for EACH PACKAGE, with the benefit of bringing ports in under the package management tree as a fall-back if the binary isn't there, and as an excellent way of helping commercial entities start selling apps for FreeBSD. Just some ideas... -- Paul Robinson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030620094730.GP20204>