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?
--bud
>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 <3.0.6.32.20000208134549.009f8c60@mail.sistema.it>, "Bud P.
>Bruegger
>" 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
other
>>>systems/arches.
>>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
>>similar...
>>- 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
>>enourmously.
>>
>>* 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
>>packages.
>>
>>* I believe that Debian would be ideally suited for such a thing since it
>>possibly has the cleanest and best thought through approach to
packaging...
>>
>>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
>>solution.
>>
>>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...
>>
>>cheers
>>
>>--bud
>>
>>/------------------------------------------------------------------------\
>>| 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: