[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian on non-Linux systems

[I'm not on this list, please cc to <bud@sistema.it>]

This is a copy of a discussion I had with Nils Lohner, the author of
"debian-scala HOWTO: Debian on non-Linux systems".  I thought this may be
of interest.  

I again take up his suggestion to move away from debian-devel to a more
quiet, specialized list.  The options I see are (ordered by my preference):

1 set up a debian-infrastructures  (I'm not a debian developer, so I don't
know what that would take)

2 we use the existing list of www.infrastructures.org.  I already cleared
with them that this is ok.  

3 I set up an inofficial debian-infrastructure list on my machine

4 we use the existing debian-beowulf list--but there may be too many
non-cluster issues coming up and cross-posting to the infrastructure.org
list becomes difficult since they may not like messages about PVM/MPI,etc.

How do you Debian people decide on such issues?


>Delivered-To: bud@sistema.it
>X-Mailer: exmh version 2.1.1 10/15/1999
>To: "Bud P. Bruegger" <bud@sistema.it>
>Subject: Re: Debian on non-Linux systems 
>Date: Fri, 11 Feb 2000 09:27:26 +0100
>From: Nils Lohner <lohner@hew.ecf.teradyne.com>
>Sender: uucp@sistema.it
>I'm swamped with real work for a week or two... my sugestion is to post this 
>to debian-devel and let others jump in, and then perhaps find a more quiet 
>list for discussion.
>Re: the technical isues you addressed, they sound very reasonable to me, but 
>I haven't worked with this enough to really say how easy/hard it would be to 
>implement- comments from debian-devel would help IMO...
>A lot of what needs to be done is laying the groundwork for this system, and 
>documenting what is done and why... then people will use, understand, and 
>want to enhance it.
>Regards, Nils.
>In message <>, "Bud P. 
>" writes:
>>Hi Nils,
>>I just write down some of my thoughts as they flow.  Apologies if I repeat
>>something of the last mail...
>>* I'm probably more ambitious in my ideas than you :
>>>I think we should go the 'apt-get source and compile' road for a while 
>>>until at least that works, and then possibly consider binary dists for
>>But it may be helpful to see the goal to reach even to make small steps.
>>* One of the great things of Debian source packages is that they kind of
>>standardize the source layout and build/install process--even if done
>>manually (and not with binary packages).  Installing from a debian source
>>(diff applied) is surely easier and less error-prone than doing from the
>>original source where you have much more variation.  
>>* In this line of thought, debianization can be seen as two things:  
>>(i) standardization of the source (e.g., consistent strategy of where to
>>put what kinds of files)
>>(ii) automation of the building and installation process in a debian
>>specific way.  
>>I believe that (i) is directly useful for any platform/OS.  And in (ii) the
>>debian specific solution can be hidden behind an API.  This makes it
>>possible to plug in either a debian specific "backend" to the API or
>>Solaris-, AIX-, etc. specific one.  
>>* Some examples shall illustrate this:  
>>- Installation of files on Debian follows the file hierarchy standard--but
>>other platforms don't conform with it.  But having the source package
>>standardized means that the debian installation can copy 1:1 and the OS foo
>>installation can install all files in the /bin branch to /opt/bin or
>>- One of the debian specific things is to add cron entries.  If this could
>>be hidden behind an API similar to "add_cron_daily (<entry>)".  On a debian
>>system, the debian backend (here the library routine add_cron_daily) put's
>>the "entry" in a file of its own and copies it in /etc/cron.daily;  on some
>>other system it may edit /etc/crontab or anything else.
>>- Similar things are possible for starting and stopping daemons, for init
>>scipts (/etc/init.d/) and runlevel management, for entries in
>>/etc/inetd.conf, for entries in the package database, etc.
>>- debconf is already going in this direction
>>* I was wondering some time ago if it wasn't possible to largely (80-90%
>>automate a translation from current to API-conformant source packages).
>>Some reasonably simple perl script that finds things such as "echo" and
>>"read" and converts them to the corresponding API call ("debconf" in this
>>case).  I imagine that this would reduce the effort of a transition
>>* I believe that the effort for doing this is not enormous.  Particularly,
>>if you believe that debian source packages will be used quite routinely on
>>multiple non-debian platforms, the overall effort for {changing the
>>sourepackage once and writing backends for each platform} is smaller than
>>changing each sourcepackage (incl. scripts, etc.) for each platform.
>>* The biggest benefit of this approach is evident when looking beyond the
>>scope of your howto:  Using this method, it seems to me that from a single
>>(modified debian) source, it is possible to (directly or indirectly) not
>>only build debian binary packages for other platforms, but also AIX, or
>>Solaris packages and, why not, RPMs and other Linux packages.  
>>* If what I outline above is a reasonable approach for what you have in
>>mind, it would provide a great boost to Debian if it came out with the
>>first kind of universal source package.  This would mean that a large
>>number of people would package their software as debian source packages
>>since with a single effort, the software could be packaged for multiple
>>distributions and platforms.  Debian would be the great beneficiary since
>>it would largely increase the availability and up-to-dateness of debian
>>* I believe that Debian would be ideally suited for such a thing since it
>>possibly has the cleanest and best thought through approach to
>>Sorry, I got carried away going way beyond technical issues.  
>>I'd be interested in your opinion on how feasible my vision is, whether you
>>think my judgement of "social benefit" is realistic, and whether a critical
>>mass of debian developers could be interested in such an approach...
>>> let me know what you end up doing.  
>>For cluster administration, my initial idea was to use apt/dpkg on every
>>single machine, controlled from a central host (the "gold server") by GNU
>>cfengine or similar.  The big problem that I see is that apt/dpkg attempts
>>to change the configuration of the local machine and this is in big
>>conflict with the goal of keeping the configuration for the whole cluster
>>(everything that is "stateful") on the gold server.  To bridge the gap
>>between local machine and gold-server-based configuration management seems
>>quite impossilbe with the current package approach.  Actually, a universal
>>source package that converts to debian-cluster binary packages may be one
>>In the meantime I'm exploring possibilities of using apt/dpkg only on the
>>gold server and using file copy and/or network filesystem techniques to
>>"propagate installation" to all other machines in the cluster.  Coda looks
>>like the most eligant and easiest solution at the moment (but it may not be
>>stable enough...).  But even in this case, I intend to manage multi-host
>>sources for configuration files from which the actual configuration files
>>are produced for every host by some preprocessor.  This requires a
>>modification of the configuration management aspects of the package tools.  
>>Debian on clusters and infrastructure is probably another good example for
>>how the "universal source package" approach is very useful even within the
>>debian domain...
>>I searched for "cluster" on the debian-devel archive today and there was
>>some talk about the need for a cluster list but I saw no evidence that this
>>was ever done.  The beowulf list has some cluster-related issues...  I
>>suppose I'll have to post the question on devel as you suggested...
>>| Bud P. Bruegger, Ph.D.  |  mailto:bud@sistema.it                       |
>>| Sistema                 |  http://www.sistema.it                       |
>>| Information Systems     |  voice general: +39-0564-418667              |
>>| Via U. Bassi, 54        |  voice direct:  +39-0564-418667 (internal 41)|
>>| 58100 Grosseto          |  fax:           +39-0564-426104              |
>>| Italy                   |  P.Iva:         01116600535                  |
| Bud P. Bruegger, Ph.D.  |  mailto:bud@sistema.it                       |
| Sistema                 |  http://www.sistema.it                       |
| Information Systems     |  voice general: +39-0564-418667              |
| Via U. Bassi, 54        |  voice direct:  +39-0564-418667 (internal 41)|
| 58100 Grosseto          |  fax:           +39-0564-426104              |
| Italy                   |  P.Iva:         01116600535                  |

Reply to: