Date: Fri, 9 Aug 2002 09:12:28 -0400 From: Antoine Beaupre <anarcat@anarcat.ath.cx> To: Jordan K Hubbard <jkh@queasyweasel.com> Cc: libh@FreeBSD.ORG Subject: Re: package format and creation Message-ID: <A7C2B402-AB99-11D6-B9DC-0050E4A0BB3F@anarcat.ath.cx> In-Reply-To: <B6911A7E-AB71-11D6-8CFD-0003938C7B7E@queasyweasel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, August 9, 2002, at 04:26 AM, Jordan K Hubbard wrote:
> On Wednesday, August 7, 2002, at 01:23 PM, Antoine Beaupre wrote:
>> 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.
>
> Obviously if the target format has a rich enough collection of
> attributes to meet libh's minimum requirements, it should be a possible
> "output" format for the package generator.
Generally, I find that *any* given target format can be hacked to have
those requirements, to some extent. The idea is only to provide those
bikesheders a clean interface to be able to confidently say "you want
that format? implement it! you have to cut here and here, paste here and
here and hack that."
> I agree that this can and should be reasonably abstracted so libh isn't
> locked into any one format (say there were a big lawsuit over zip and
> suddenly we had to abandon it as GIFs were abandoned for jpegs). The
> only thing currently driving zip is that it meets the requirements
> nicely, but that's not to say that it will always be the only
> reasonable format.
Indeed, I think the image format is much more suitable as it provides
possibly better compression without the cost of losing random access.
I won't be rewriting libh to switch the package format yet though. ;)
Just provide a cleaner interface.
>> How is a package created? The current pkg_tools scheme is not good
>> enough since it requires installing *and* registering the package in
>> the system to package it, which is a bit absurd. The current libh
>> scheme is a bit better since it installs the thing in a temporary
>> location.
>>
>> We can do better.
>
> Good luck.. :-)
>
> There's nothing absurd, unfortunately, about the sheer amount of
> software out there which through its build procedures or its code
> depends on having things in a fixed location. When you run the
> configure script for program A which depends on program or library B,
> those fancy configure scripts will prowl the system looking for B in
> all of its "canonical locations" will either fail to locate it if it's
> not in those places or, once they find it, will compile right into
> program A the location of B. If you then move B elsewhere, program A
> will break. Even without dependencies, program A will very often hard
> code the dependencies it has on its own internal components (like doc
> or config files) and will derive those paths from its build phase. Do
> you really want to "fix" all of that software as a prerequisite to
> packaging it with libh? I honestly don't think so, and the sheer pain
> of making things relocatable will be large enough that it in itself
> will become a significant barrier to entry for new package writers if
> you mandate it as part of the system. The FreeBSD ports collection
> side-steps a LOT of hairy issues by simply installing a dependency
> fully and to its final destination before going back to the depending
> port and resuming its build. The same situation maps to pkg_add.
>
Yes, yes... I've had a discussion "on that irc channel" that led me to
conclude this idea had after all limited appllication.
The basic idea behind the mapping file was to extend current's plist
format in order to accomodate both a non-install package creation
procedure and libh's special sub-package requirements. The mapping file
scheme can be used with the current "install and package" packaging
scheme without problems.
I now realize that non-install package creation could be useful in only
certain kind of (nice) software (eg ROX) that don't rely on absolute
paths (eg *not* openssh). I think it would be nice to encourage that
though. Also, note that the current libh package creation scheme uses
the plist stuff and make install in a TMPDIR. And it works (for xv ;)).
The discussions on -arch wrt that were interesting because they actually
provided solutions to the "PREFIX problem". Terry was always coming back
to the "we need a registry" solution, that I found interesting. Well,
with libh, we'll have a database of installed software. Recording the
prefix of each installed package and providing an API will then be a
piece of cake.
Now if people could just use the API ("yeah right, dream on"). ;)
A.
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?A7C2B402-AB99-11D6-B9DC-0050E4A0BB3F>