Re: PACKAGES info file into cvs?

[Martin Pala]

Hi,

the hint was motivated to bring standard where it isn't. There are many of
packaging methods/systems for many platforms. These systems have common
target - create package from source files. "Make" is very general tool
suitable whenever you need to create one or more target from given entry
data set => i think that it is possible to use it in this case to provide
abstraction for users for creating monit packages (there can be many targets
representing many platforms - every with its own rules to create package
from source). It is prety simple to do "make solaris" (or
redhat/suse/debian/etc.) - the user don't need to know anything about
packaging system that it involves.

In attachment is sample Makefile.in and support files for creating solaris
packages from sources (taken from Zmailer - http://www.zmailer.org). I think
that it is possible to do something similar for monit.

The most important is to keep it simple. Many users probably woun't never
create its own packages and will use even precompiled packages from monit
packagers (thanks for good work boys :) or directly monit sources => if this
stuff will be to complicated (it was realy only idea), it will be better to
create monit packages with present contribs.

Best regards,
Martin

----- Original Message -----
From: "Christian Hopp" <address@hidden>
To: <address@hidden>
Sent: Tuesday, July 16, 2002 10:07 AM
Subject: Re: PACKAGES info file into cvs?


On Tue, 16 Jul 2002, Martin Pala wrote:

> Yeah. Maybe it will be useful to have common Makefile (either realy
> common/single by extending  present Makefile or new in ditributions
> directory) for building distributions from sources. It can be then
possible
> to do:
>
> make redhat (or suse/solaris/debian/etc.)
>
> that will make apropriate package. I think it will be simple and
consistent
> packaging method.

So, you have all the package generation "code" in the main Makefile?
Doesn't sound anyhow complicated and a bit more consistent then
running a pile of different scripts for every OS.

But, might be a bit tricky for some OSes.  Debian needs usually it's
"debian" directory with a bunch of scripts and additional files.
Solaris  needs its obscure pkginfo/prototype file.  RPM based OSes do
need usually different specs, some need even different init.scripts to
be included.  Should all those files be already available or should
the be made in configure? Remember changing version numbers, dates,
descriptions, file lists all those have to be maintained.

There should be some kind of files around clearly marking files have
to be installed (like DOCUMENTATION or FILES).  It's maybe easier to
maintain than hacking the Makefile.in or configure.in, everytime
somebody makes a new doc or whatever file.

> The PACKAGES file can then contain instructions for adding new
> package type. It can also contain specific notes for packages or
> they can be separated in more README files for given system (for
> example README.solaris, etc.)

I think it's first of all important to have a README.<os> with every
package with information about installation / deinstallation /
generation of the package.  That makes it easier for the user to read
the necessary stuff compared to scanning through a PACKAGES file.

On the other hand the PACKAGES file give better access to the
information "who does what package".  Thus, this better for the
developers and packagers.

> What do the people on the list think about it?


C.Hopp

--
Christian Hopp                                email:
address@hidden
Institut für Elektrische Informationstechnik             fon:
+49-5323-72-2113
Technische Universität Clausthal                         fax:
+49-5323-72-3197
  pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/chopp.key.asc
(2001-11-22)


--
To unsubscribe:
http://mail.freesoftware.fsf.org/mailman/listinfo/monit-general

Readme
Description: Binary data

pkginfo-01.src
Description: Binary data

pkginfo-02.src
Description: Binary data

Makefile.in
Description: Binary data