Long Discuss: Packaging, layout, upgrades and modularity

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Long Discuss: Packaging, layout, upgrades and modularity

Michael Brown-2
Hi Folks!

I thought I'd throw some ideas up in the air, and see
what those more knowledgeable than myself have to say
about them.

My first thought was about the packaging (and thus
layout) of mh for each release.  Mh is relatively
cross-platform in that in runs on Win32 and *nix,
which I think is great.  However, there is a lot of
territory on the *nix side.  It would be nice to have
package management support on some of the platforms,
in order to make future upgrades easier.  Debian
(which I use) has apt, and rpm based distros have lots
of options with rpm, yum, Yast, etc.  One of the OSS
projects I work with (Opengroupware.org,
http://www.opengroupware.org ) houses build scripts in
the actual source repository, by which release
packages (and nightly builds) are made.  It would be
nice if such package build scripts could be housed in
the mh repo instead of on private websites, so that
the lives of the various package maintainers could be
simplified accross mh releases.  I know that there are
Debian packages of mh, and I suspect there are rpm's
as well somewhere, so this could be beneficial to
many.  

As far as layout goes, maybe the repo could be
modified to take the needs of the build scripts and OS
environments into account, based on feedback from
those familiar with building packages for their
platform.   You could take a look at
http://svn.opengroupware.org/OpenGroupware.org/trunk/
for some examples of layout to accommodate build
scripts (note specifically the 'debian' directory,
containing debian specific environment, scripts, etc.
for building .debs).  Since Sourceforge is rolling out
svn sometime soon, maybe the mh repo could be imported
into svn, and then things could be moved around in
svn, so that those who track the repo can stay
up-to-date with the latest layout.

I would also like to suggest some modularity be built
into the mh project/repo.  I can't speak for Bruce,
but it seems to me that pulling a release together for
him must be a lot of work.  My suggestion would be to
have a mh 'core', and then modules which add
functionality (and can be installed
seperately/optionally).  Webmin is a good example of
what I'm suggesting (http://www.webmin.com).  It has a
core, and then you can install optional modules to add
features you need, or delete un-needed ones.  This
approach has several benefits: a minimal but stable
core, which focuses on the UI, API's and core
features, which is smaller and easier to test come
release time.  Modules would put the onus on the
module developer to test against the core.  It could
also benefit by reducing the number of unmaintained
files in the mh package.  I seem to remember about 3
Asterisk scripts, a half-dozen rc.startup scripts, and
a bunch of other scripts with modification dates of a
few years ago.  I'm not trying to say that those are
not useful; merely that the sheer number of files make
it somewhat overwhelming to someone new to mh.

The other nice thing to the Webmin approach is that it
has a built-in upgrade and module installation system.
 The benefit to this is that the mh core could be a
smaller package, and once someone has a functional mh
install, they could add modules to flavour, and have a
one-button upgrade when each release is made.

I'd like to thank Bruce and all those who have made mh
what it is today.  All that it contains, and the
number of people who use it (and this mailing list)
are a tribute to all you have accomplished.  I offer
these suggestions/ideas in the hope of making your
lives easier, and similarly for those who use mh.  I
look forward to reading (learning, and participating)
in the discussion created by these ideas by those more
knowledgeable (about mh, packages, and build systems)
than myself.

Cheers!

/Mike


       

       
               
__________________________________________________________
Find your next car at http://autos.yahoo.ca


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

Reply | Threaded
Open this post in threaded view
|

Re: Long Discuss: Packaging, layout, upgrades and modularity

David H. Lynch Jr.


Michael Brown wrote:

>Hi Folks!
>
>I thought I'd throw some ideas up in the air, and see
>what those more knowledgeable than myself have to say
>about them.
>
>My first thought was about the packaging (and thus
>layout) of mh for each release.  
>
    Just discussing file layout and organization on a Linux system is
likely to provoke a religious war.

    The typical mh linux install, diverges significantly from the way
debian wants things.
    I believe there is also a set of rules defined by the Linux Standard
Base, that most
    distributions are trying to move to.

     There is a great deal of thought as well as some fairly arcane
logic behind the file layout on the various Linux distributions. Allot
of the thought is about issues most of us really do not care about. but
violating them will inevitably provoke somebodies wrath.

    I primarily use Debian. And I like it allot. When I am really in the
mood for self flagelation I install Gentoo.
    But I would not dream of trying to propose a file layout for a major
project to the debian community without expecting to get seriously flamed.

    Despite this ranting, and religious feuding, in comparison to
windows all Linux distributions have a fairly well thought out and
organized layout for projects, and even despite violent religious
differences on some fairly subtle details, the commonality is enormous.
There is allot less you can really be sure of on a windows system.




--
Dave Lynch DLA Systems
Software Development:       Embedded Linux
717.627.3770     [hidden email]      http://www.dlasys.net



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365