Re: Package managment idea...

[Matthew Berg <wdomburg pce net>]

> > I personally think it makes a lot of sense. There are a lot of issues
> > that come up in installing a package -
> 
> But none of them require package-specific actions. That's what
> InstallShield is for. All these can be handled by a package manager and
> proper package formats.

I see the problem here - when I said installer, I did not mean it as a
package specific entity.  

What I was refering to was a single program that could deal with package
installation.  I would prefer it NOT be a full package manager.  That
would be as ridiculous as using a file manager as a file open dialog.

> >   What prefix should be used for the install?
> 
> Packages can just be retargetable (though prefix is not nearly as
> important with good packages, it's only needed because you might want to
> spread packages across devices.) Then the package manager can decide on a
> prefix.

The issue I was refering to was having a double click on a package
automatically installing it without first asking for a prefix, hence the
need for a generalized install program. 

I personally don't agree with the idea that package relocation isn't
important,  especially considering the cross-platform nature of GNOME. 

I suppose if you were releasing binaries for a variety of platforms, you
could ensure each was packaged in a platforms native format, using the
proper conventions, etc, etc...  But personally I think that is placing
entirely too much burden on the programmer (or requires that the
maintainer of each platforms binary package go through the hassle of
packaging and following conventions.)

Not to mention that it ignores the sys admins desires.  Suppose, for
example, I have an NFS server I have export filesystems for a farm of
diskless Netwinders - it would be convienent if I could simply pick up
an ARM/Linux binary, and install it to, e.g. /usr/export/ARM/.

> >   Should the install be forced if dependency checks fail?
> 
> Apt simply won't let you do this. Once the system gets into an
> inconsistent state like this, very little can be automated. (dpkg on the
> other hand does let you do it.)
> 
> But more importantly, this is something dpkg, apt, or rpm can detect - not
> something the package creator needs to fool with.

The fact that the dependency can be checked by the package manager is
besides the point (rising I suppose from the miscommunication we have
had).  

As a sysadmin, if I choose to ignore dependency warning, I should not be
prevented from installing.  Take for example, my brothers machine, which
was available as a 24x7 DNS, print, and backup server.  His RPM database
got corrupted somehow, and the backups on file all had the same problem. 

He could not afford to take the machine down at that time, and he needed
to get a package installed.  Should he be forced to compile from source
since he has a fubared package database?  
 
> >   If I run into conflicts for particular files (e.g. I'm installing a
> > copy of       GTK+ 1.1.9 as well as my old 1.0.6, and the header files
> > conflicy) should
> >   I overwrite those files, skip them, fail out of the install?
> 
> dpkg detects this situation. Again, it is not something the package needs
> to worry about.

Again, this seems to be brought up only because of our
misunderstanding.  

I agree the package shouldn't worry about it, but it is detected by the
package management routines, and should be not only detected by an
installation program, but also give the user the choice of actions as I
indicated above.
 
> >   Should I create an entry in /usr/share/apps?  If so, what group?
> 
> Ditto. (though the standard thing right now is to hardcode this, it
> appears.)

*nods*  The hardcode idea seems to me poor.  I would prefer if I were
given a choice in this matter.
 
> > Furthermore, if sub-packaging is installed, as is proper, that
> > necessitates yet another piece of user interaction for the installation.
> 
> This is just part of selecting which packages to install - again, a
> package manager issue, not a package issue.

Agreed, I won't cover this, since it seems we were laboring under false
impressions of what the other was saying.

> > Yes, you could have each individual install script set up to spit out
> > messages to stdout or to a gui shell, but isn't that a pointless waste
> > of effort?  And of course that assumes that each package maintainer is
> > going to maintain both the gui and text mode messages, which I find
> > unlikely.  It's more work for the programmer and will likely lead to
> > less consistancy and ease of use for the end user.
> 
> I think maybe we agree: what's needed is a package manager like gnome-apt,
> not an InstallShield program. InstallShield is a package-by-package hack,
> where the developer of each package decides what questions to ask and what
> an install involves. A package manager is a program to manage packages;
> packages themselves are "dumb" and simply export the necessary information
> - dependencies, menu entries, and so on.

*nods*  We definitely agree.  What my point was, as I've stated, that a
stripped down package program (meant specifically for installation)
would be a Right And Goodly Thing (TM).  

> But again, this is a function of the package manager, whether packages are
> "retargetable" to a new prefix (Gnome, for example, is not retargetable in
> binary form! I think this is true of many complex programs), whether the
> menu information is "exported" or package-internal, and so on.

*nods* Again we are agreed, the package system itself requires these
functions to be present. 

My other point is that all package manager have to deal with (try to
deal with? fail to deal with?) the same issues, and it is pointless to
have a seperate front end for each package format.  Not only is it
replication of effort, it presents an inconsistency to those having to
deal with multi-platform environments, especially if one if attempting
to do this remotely.  

One thing I forgot to mention in my origional post was that the use of
CORBA backends for the actual installation is that, utilizing IIOP, you
could remotely manage packages on different machines (using any package
format) from a central location. 

As Linux will probably appear first on the corporate desktop, rather
than on home machines, this would be another major warm-fuzzy to give IT
managers.  

One of the hot sellers in the corporate world are desktop management
tools to allow for remote installation.   On the windows platform, it
costs thousands to deploy this kind of solution; on Gnome, all it would
take is utilizing the excellent CORBA framework we already have.
 
> It can all be done within the context of existing package managers, IMHO.
> All you need are standards-compliant packages and appropriate standards.

As I pointed out, GNOME, as well as most other GNU software, is
cross-platform by design, and one of the complaints about using it on
non-linux platforms is that there are no packages, so they are
completely outside the realm of package management.  (Noteable
exceptions would be HP and SCO who do maintain packages of common
utilities.)

Not to mention that this represents a duplication of efforts by
maintainers.
 
> i.e., I'm in the "not a Gnome issue" camp. The only way to do this is to
> make packages work well, and there's no way Gnome has any relevance to
> that. All Gnome can do is provide a nice GUI frontend for whatever
> solution comes about.

GNOME could present a decent cross-platform, back-end independant
solution to the problem.  The only reason I am suggesting a meta-format
is that I know of no free package manager that currently supports all
the necessary information, nor one that ENFORCES requirements such as
relocation.

One of the ideas that was tossed around on during the discussion was
that data file locations and other information affected by install
location be kept in a centralized location by the package manager, or by
GNOME itself if the back-end package manager doesn't support that
information.

> The problem with a general all-package-formats solution is that all
> package formats would have to adhere to some strict standards. Good luck
> on that. The only reason Debian works is that each developer has only a
> few packages so much time is devoted to each one, and all 2000 are
> carefully tested to see that they work together. The complexity of package
> creation and management is mind-boggling.

An all package format solution of course would prevent some
difficulties, but if worst came to worst, you could have the front end
grey out the fields not supported.
 
> Have a look at http://www.debian.org/~hp/gnome-apt.html sometime, it is
> pretty nifty I think (I'm not bragging, 'cause all the cool parts are in
> the backend which I didn't write.)

*nods*  When I get my debian system installed, I'll definitely give it a
try.  Of all the package management solutions I've heard about, Debian
does seem to be one of the better ones.  Though, as I said, the lack of
sub-packaging is major shortcoming. 
 
> The frontend is actually very little code; all the work is in the backend
> and in making the packages, and it has to be done by the distribution or
> vendor.

Understandable. And because of that, wouldn't it be advantageous to
create a meta format to define the necessary information once - for all
platforms, for all package management solutions?