Date: Thu, 8 Aug 2002 10:14:45 -0400 From: The Anarcat <anarcat@anarcat.ath.cx> To: Max Okumoto <okumoto@ucsd.edu> Cc: libh@FreeBSD.ORG Subject: Re: package format and creation Message-ID: <20020808141445.GA24117@lenny.anarcat.ath.cx> In-Reply-To: <hf8z3idxua.fsf@multivac.sdsc.edu> References: <7F90C363-AA43-11D6-9D65-0050E4A0BB3F@anarcat.ath.cx> <hf8z3idxua.fsf@multivac.sdsc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed Aug 07, 2002 at 04:59:41PM -0700, Max Okumoto wrote: >=20 > Yea, I saw those threads in -arch and I ducked. :-) I think we need=20 > to come up with some 'use cases' of the common usage for libh. >=20 > Senario 1 (System to be used by programmer) > Senario 2 (System to be used by email, netscape user) > Senario 3 > .... > > What type of environment will libh be running? > 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. >=20 > What is final configuration that should end up on the installed disk? Indeed, libh should provide for all these use cases, but in a generic manner. Although I'm not sure libh should fulfill all the reasons you mention in that listing there. "restore from backup" is the first thing that seems a bit to stretched for a libh use. However, this shouldn't affect design decisions otherwise than saying: "fine, here's libh, you can do a lot of things with it, but you'll have to write the scripts". In other words, provide a clean way, and a clean interface to write such script but don't rot too much on bits that wouldn't be useful to all configs. These can be written outside libh without problems. libh is, for me, 2 things: - console or Graphical UI - package library the rest is extensions, and we must not focus on those yet. Those extensions will have to be written for seperate package configurators (e.g. the "net" package configurator or "apache" configurator, etc). =20 > Antoine Beaupre <anarcat@anarcat.ath.cx> writes: > > Hi. > >=20 > > Yesterday night I was bored and I wrote up a little something about=20 > > package formats and sources. > >=20 > > Semantics > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > A "package format" is defined here defined as the "media" of the packag= e=20 > > itself. In the pkg_tools days, it's the .tgz with +METADATA. Right now,= =20 > > in libh, this is a zip file with METADATA/*. But what are the actual=20 > > possibilities? Why restrict libh to a single format? This would merely= =20 > > make libh more vulnerable to its detractors. >=20 > I like this idea! I think we need to examine the reasons people argue > for different package formats. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > 3. Resource limitations. How much space can FreeBSD.org and > mirrors dedicate to storing releases/snapshots? >=20 > 4. Creating a new release or rolling your own. How difficult > are security updates? (Binary updates) =20 >=20 > 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. You'll soon find out that this will simply be impossible. There Can Be Only One. Packages need to be built. It might be possible to build multiple format, but I'm still skeptical. It already takes a lot of time for bento to catchup on changes in the ports tree, and this is a critical point: libh will be more package-oriented. Packages will need to be promptly built. =20 > FreeBSD.org:/release/Packages/ > meta/ - data describing packages > tar/ - maximum compresion > iso/ - maximum convenience >=20 > cdrom:/release/Packages/ > meta/ - data describing packages > tar/ - maximum compresion >=20 > lazy.com:/release/Packages/ > meta/ - data describing packages > tar/ - maximum compresion > iso/ - maximum convenience I don't suggest seperating meta-data from packages themselves, and I don't think it'd save anything. I rather think packages should be self-contained. We already have enough problems tracking multiple-package dependencies, we don't want to track in-package dependencies! Anyways. A. --=20 =46rom the age of uniformity, from the age of solitude, from the age of Big Brother, from the age of doublethink - greetings! --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9UnzUttcWHAnWiGcRAiRZAJoDLALJU9Q+jwq9LDHdEizuX0JZcQCeIaEh qJnzag7bkDSgBLUlm2uLobA= =CECz -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- 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?20020808141445.GA24117>