<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> we have features which make handling of big number of interdependent packages<BR><BR>
<BR>
So, maybe we should just have a package per directory, cm3-foo (cm3-cm3, cm3-m3cc, cm3-m3core, cm3-libm3, cm3-ui, m3-vbt, cm3-formsedit, etc.), and leave just the old min and all for people not using packages?<BR>
Is that ok or obnoxious?<BR>
<BR>
<BR>
When we get really advanced, cm3 -ship will have flags -rpm and -deb or such (and -addtar?)?<BR>
<BR>
<BR>
On the matter of config files btw, there are maybe three "levels":<BR>
1 not edited by anyone <BR>
2 edited by (every/many) root/admin/installer <BR>
3 edited by every user <BR>
<BR>
I wasn't trying to distinguish between 2 and 3, but rather 1 and 2.<BR>
If few root/admin/installers edit the files, just like they don't edit "binaries", then it is #1.<BR>
If every/many do, then #2.<BR>
Just because it is a text file, doesn't mean it is meant to be edited.<BR>
It is a gray line between compiled code in cm3 and script in cm3.cfg.<BR>
Ultimately root can edit any file anywhere, be they text files outside of /etc or binaries in /usr/bin.<BR>
<BR>
I do think though there is a question of what "upgrades" do, if "upgrade" is free to overwrite files, is obligated to leave them alone, or is obligated to merge. Here again, as in many things, I think many people (not necessarily here and certainly not limited to here) believe in a truth that they believe is obvious but in fact there is probably no good answer.<BR>
<BR>
There may be other issues here. I don't know what all is implied by a file being in /etc vs. /usr/local/etc vs. /usr/local/bin.<BR>
<BR>
To be more constructive though..maybe we should discuss just how people tend to edit their config files?<BR>
Do you put in full paths to cc, gcc, ld?<BR>
Or is $PATH search a good compromise that folks can live with?<BR>
I'm a little conflicted on this matter, because often for cross builds you have platform-gcc instead of gcc. I could make a symlink and alter path, but I don't know if there is a clear best. Maybe cm3 should do something here? Maybe $CC environment variable is the way?<BR>
Do you edit the compile/link flags?<BR>
Maybe $CFLAGS/$LDFLAGS we should use??<BR>
Have you rewritten them entirely? :)<BR>
Have you further factored/merged some of the reduncancies or odd factoring I have left in? (Unix.common vs. Darwin.common vs. Solaris.common vs. HPUX.common is still a bit wierd and not always the right balance.)<BR>
Are there just a few environment variables or command line switches we can put to capture what people do?<BR>
I know about lib64.<BR>
<BR>
- Jay<BR><BR>> From: dragisha@m3w.org<BR>> To: wagner@elegosoft.com<BR>> Date: Thu, 28 May 2009 15:57:02 +0200<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages<BR>> <BR>> On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote:<BR>> > All bin packages are pre-built and can be installed with the<BR>> > included install.sh (which simply executes cm3 -ship multiple times).<BR>> <BR>> As I said, this kind of binary packages are not something Linux people<BR>> want.<BR>> <BR>> Also, in standard RPM based distro (and most are, except ones which are<BR>> Debian based but they have similar packaging philosophy) we have<BR>> features which make handling of big number of interdependent packages<BR>> easy task. Installation of cvsup on fresh system will pull suplib and<BR>> also package(s) with m3core/libm3/set/parseparams/patternmatching<BR>> libs... Big number of packages or not, it's something RPM (system) will<BR>> do for me.<BR>> <BR>> I have some (RPM spec file) templates developed which enable making<BR>> packages which contain interdependent packages and once I get content of<BR>> your packages (combined with some free time) I will make spec files with<BR>> same content.<BR>> <BR>> -- <BR>> Dragiša Durić <dragisha@m3w.org><BR>> <BR></body>
</html>