[openbeos] Re: Installer Proposal

To start with, you really need to make clear what this installs - this is an 
application installer. Not an OS installer. :-)

>Attached is the first part of my installer proposal. I am willing to 
>code it if the idea is 
>supported by the rest of you lot. Here's a summary of the goals and 
>features of the 
>installer:
>- Provide a standard interface for customized installers
>- Create perfect uninstallers instantly
>- Support for dependencies
>- Centralized database

Yikes! Smells like the registry.

>It is a replacement for SoftwareValet. This means that any package compiled for
>OBOS will install on all the different distributions derived from it.  Please 
>read the

Install != function, necessarily. ;-)

>first two paragraphs, as the third one already goes into somewhat more detail.
>I'd like to get started on the library ASAP, however, I am eager for your 
>comments. 
>
>Niels S. Reedijk

>OBOS INSTALLER PROPOSAL
=================
This document describes the Beatrice project, a project that tries to create
the perfect installer software. All rights reserved.
Copyright (c) 2002, Niels S. Reedijk

A proposal to an open source project, where the author claims copyright scares 
me
a little, too... 

1 INTRODUCTION
---------------------------
SoftwareValet sucks. When I first started to look through the comments on the
internet about the current BeOS installation system, I was shocked by the tone

I think that we all agree here...

of the comments on it. For OpenBeOS we need an open installation standard, if
we're ever going to get a standard distribution. Thus having a public API 
defining

Did I, at some point, state that this was a goal? :)

an installation standard is absolutely required. This document tries to describe
what my ideas and plans for 'Project Beatrice' are.

2 INFRASTRUCTURE
-------------------------------

<snip>

        A comment I am expecting to hear is that we will not allow any new API's
for the OBOS R1 release. While it is true that this will break that convention, 
I
would like to remind everyone that having a new kit like this one is required in
order to properly maintain installation tools. One part where Windows has 

I don't want to disappoint you. ;-)
No new API's. None. 0. 
Not SDL (becaise it is needed for portable games)
Not SSL (because, well, all of these internet apps need it anyway)
Not XML (because Microsoft says so)
Not HWOGL (because it would be 31337)
Not me, not now. ;-)

graciously failed is in fact the installation part. A common tool throughout
the distributions will make sure that 3rd party apps will never show this
behaviour. Furthermore, it sort of demands a quality standard required for
proper 3rd party apps. 

We all agree that Windows has an issue, here. 

        It is not entirely fair to reject this proposal because it enacts a new
kit. Because it really isn't a new kit. The current API isn't changed, so no 
real

It is *absolutely* a new kit. What you are proposing is an installer kit. 

harm is done. Also, the current softwarevalet system can be maintained
using a compatibility layer. So it only adds necessary functionality.

Adding functionality is exactly what we are avoiding by saying "no new 
functionality".
In the industry, it is called feature creep. It is a bad thing. 

        Another argument against this approach is that it is rarely
needed to have custom installers. We'd better write the perfect 
installer. The perfect argument against that is when we look at distributors.
They probably have their own means of getting online updates and how
users can install software. However, third party software will probably
have a different installer. Or think about an application that fetches
additional modules from the internet and installs these. In all these cases
there is no separate installer needed, it can just be done via the installation
API. 

I don't believe that any of us, right now, can say that this is the "one true 
way" to do
installers. I am fairly sure that UUID's and a registry are not the best way. 
That is my
2 minutes of reading - snap idea. But I don't know what is and what isn't. This 
is why we
are feature frozen. So that we don't have to consider these ideas right now. We 
know what
we are doing and where we are going. This is really a great topic for Glass 
Elevator. That
is the proper place to discuss this sort of thing. There are all sorts of 
people over there who
are very future looking (myself included) who can help you hash this out and 
have it ready 
for serious R2 consideration.

<MEGA-SNIP>

Other related posts: