[openbeos] Re: Haiku distro guidelines [was: Haiku VmwareBuild Environment]


Am 17.04.2008 um 21:27 schrieb Ingo Weinhold:
On 2008-04-17 at 19:42:05 [+0200], Andreas Färber <andreas.faerber@xxxxxx > 
wrote:

Am 17.04.2008 um 15:00 schrieb Ingo Weinhold:
Now I'm really confused! Currently these Optional Packages are only
available to developers, building their own images. Does this move of
yours mean you want to turn Haiku itself into a distribution, with its 
own official run-time package system and format?


Nope, these files are intended only for optional packages. Regarding
distributions, particularly Haiku Inc.'s own, the general sentiment was to include third-party software. And I have a certain suspicion how a third party software that is available as optional package will be installed on the distribution image: By enabling the respective optional package. (This is probably even a good thing and, I guess, the whole distribution should 
be built like that.)


If yes, then you shouldn't do this in such a hurry.
If no, then there will be a much simpler solution: Not knowing Jam I'm 
pretty sure this info could be specified inside the Optional Package
definitions in their Jamfiles and be collected at build-time, whether
concatenated to a file or stored as attributes. No new metadata text
format describing more than needed to display the copyright info in
AboutSystem would be necessary in that case.
Mmh, I see little difference between adding the info to some jam rule and 
just putting it in a separate text file. The advantages of including a
separate file in an optional package zip are, that they will never be out of sync this way, and that even if someone accidently stumbles upon such a 
optional package zip, it will still contain the description file.


Btw including a file of fixed name in the zip file which is, as you
say, being unzipped to the image sounds like it would get overridden
by the next package. Jars do have the fixed META-INF folder, but
they're not usually being unzipped, especially not to the same folder.
Save for direct installation in a directory (and I'm going to change that), all zips are first unzipped into a temporary directory and then copied to 
the image. Between these two steps I will simply add the check for the
description file, concatenate it to a big file, and remove it. At the end 
the concatenated file will be copied to an attribute in AboutSystem.

The change in build_haiku_image should really be only a few lines and
switching to another method wouldn't be a big deal. The greater change is 
in AboutSystem.


Also while I agree that adding the copyrights to the AboutSystem app
is right, I'd like to throw in whether Linuces actually do that? I
don't really think we should worry too much about the Optional
Packages as such; more important would be making the developer adding
such Optional Packages to her image aware of their licenses.
Currently, the unzipping of the Optional Packages appears to be one of the last things done for building an image, so maybe that could show a short message on their license? (e.g. "Unzipping Firefox.zip... (MPL)")
With the description file in the zip file it is actually quite easy to do 
that -- after unzipping of course.
Well, in that case your proposed file format still contains too much info. :-)
If it's just a storage format for AboutSystem, then all you need is name, copyright, license and optionally URL. A description is only necessary when it allows the user to decide whether or not to install (when browsing a list of packages on a server), and versioning afaiu needs to occur through the filename or otherwise it's not downloaded again.
So if you do want a full-blown, self-describing installation package, then I do not understand why you want to define this format over night instead of evaluating prior art first - RPM, Deb, Autopackage, etc.
Also, as someone working towards helping with the Optional Packages, I see it as more difficult to get such a file (in whatever format) inside the same zip rather than storing it externally. Jars, RPMs and others are not created manually from `make install`, there are special tools, with text file input, to generate the packages. This would still be missing if defining a format and manually adding such files to existing zips. 

Andreas

Other related posts: