Date: 07 Aug 2002 16:59:41 -0700 From: Max Okumoto <okumoto@ucsd.edu> To: Antoine Beaupre <anarcat@anarcat.ath.cx> Cc: libh@FreeBSD.ORG Subject: Re: package format and creation Message-ID: <hf8z3idxua.fsf@multivac.sdsc.edu> In-Reply-To: Antoine Beaupre's message of "Wed, 7 Aug 2002 16:23:13 -0400" References: <7F90C363-AA43-11D6-9D65-0050E4A0BB3F@anarcat.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Yea, I saw those threads in -arch and I ducked. :-) I think we need
to come up with some 'use cases' of the common usage for libh.
Senario 1 (System to be used by programmer)
New machine with one large disk, cdrom drive.
Install FreeBSD as only OS.
Development enviornemnt {complier, libs, man pages, etc.}
Senario 2 (System to be used by email, netscape user)
New machine with one large disk, cdrom drive.
Install FreeBSD as multiboot with MS Windows
Binary only system.
Senario 3
....
....
....
What type of environment will libh be running?
o from floppy disk.
o from CD-ROM.
o from network boot.
o from running system.
What are Reasons people run libh?
o Install system to main disk.
o Install system to alternate disk. (build systems)
o Restore from backup.
o Add new hardware resource.
o Change configuration.
o De-install system from main disk.
What is final configuration that should end up on the installed disk?
o PicoBSD
o Kitchen sink
o X-Window user
o Software devel
o Kernel devel
o Diskless
Antoine Beaupre <anarcat@anarcat.ath.cx> writes:
> Hi.
>
> Yesterday night I was bored and I wrote up a little something about
> package formats and sources.
>
> Semantics
> =========
>
> A "package format" is defined here defined as the "media" of the package
> itself. In the pkg_tools days, it's the .tgz with +METADATA. Right now,
> in libh, this is a zip file with METADATA/*. But what are the actual
> possibilities? Why restrict libh to a single format? This would merely
> make libh more vulnerable to its detractors.
I like this idea! I think we need to examine the reasons people argue
for different package formats.
1. Limited space on CDROM. Since many people install FB from
cdrom we want to limit the number of times they switch disks.
DVD drives are just a scaling factor.
If the user has a large enough disk we can address some
of the inconvenience and speed issuses by copying the all
the data from the CDROM to disk.
2. Network limitations. The obvious problems are bandwidth and
reliability. Can the transfers be restarted? Can sections
be skipped? How do we know what we can down load?
3. Resource limitations. How much space can FreeBSD.org and
mirrors dedicate to storing releases/snapshots?
4. Creating a new release or rolling your own. How difficult
are security updates? (Binary updates)
I would argue that there is no reason to only have the packages stored
in one format. As long as we automate creation of packages we can store
as many formats as required to address the problems above on the server.
FreeBSD.org:/release/Packages/
meta/ - data describing packages
tar/ - maximum compresion
iso/ - maximum convenience
cdrom:/release/Packages/
meta/ - data describing packages
tar/ - maximum compresion
lazy.com:/release/Packages/
meta/ - data describing packages
tar/ - maximum compresion
iso/ - maximum convenience
> As for "package source", I mean by that how the package itself is
> created. In the pkg_tools scheme, it's the "make install" and pkg_create
> procedure directed by a plist, and it's quite obscure, IMHO. In the
> current libh scheme, well, I'm not sure it's even that well defined.
> People can reference release/scripts/pkgtools/makepackage.sh to see
> what's the current procedure, but this script shouldn't be considered as
> how things *should* be, because, obviously, libh new package system will
> need a re-work in the ports system. Anyhow, right now, this package
> creator makes an install in a temporary directory and uses the plist to
> add files to the package.
>
> So here are the possibilities I thought about:
>
> Package formats
> ===============
>
> Regardless of the physical file format and location, the content of the
> package should be the same: some meta-data in a SYSINSTALL (or whatever)
> directory, and the "data files" (files to be installed) in the root of
> the file.
>
> Here are the considered package formats:
>
> 1- zip file (current package format): allows comment and customizable
> inline archive properties, random access and moderatly powerful
> compression
> 2- FS image (ISO, FFS or else, possibly compressed): random and fast
> access, compression dependent on the system's facility to mount
> compressed images, might be requiring temporary extraction space
> 3- .tar.[gz|bz2]: no random access without temporary extraction,
> powerful compression
> 4- .foo (insert you favorite archive scheme): must allow good
> compression, preferably accessible through library calls, preferably
> also allow random access
>
> It's been originally thought the zip file was the best choice. I still
> think it's a pretty good choice, but the FS image format is very
> attracting too.
>
> At any rate, it is clear for me now that libh will have to
> *architecturally* abstract the package format. Right now, it's too much
> integrated in the system and a bit of changes will have to be done to
> libh to eventually support other formats.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hf8z3idxua.fsf>