[M3devel] CM3 RELENG: suggestion for distribution packages

[Jay]

 > we have features which make handling of big number of interdependent packages


 

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?

Is that ok or obnoxious?

 

 

When we get really advanced, cm3 -ship will have flags -rpm and -deb or such (and -addtar?)?

 

 

On the matter of config files btw, there are maybe three "levels":

  1 not edited by anyone 

  2 edited by (every/many) root/admin/installer 

  3 edited by every user 

 

I wasn't trying to distinguish between 2 and 3, but rather 1 and 2.

If few root/admin/installers edit the files, just like they don't edit "binaries", then it is #1.

If every/many do, then #2.

Just because it is a text file, doesn't mean it is meant to be edited.

It is a gray line between compiled code in cm3 and script in cm3.cfg.

Ultimately root can edit any file anywhere, be they text files outside of /etc or binaries in /usr/bin.

 

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.

 

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.

 

To be more constructive though..maybe we should discuss just how people tend to edit their config files?

Do you put in full paths to cc, gcc, ld?

  Or is $PATH search a good compromise that folks can live with?

  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?

Do you edit the compile/link flags?

  Maybe $CFLAGS/$LDFLAGS we should use??

Have you rewritten them entirely? :)

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.)

Are there just a few environment variables or command line switches we can put to capture what people do?

I know about lib64.

 

 - Jay

> From: dragisha at m3w.org
> To: wagner at elegosoft.com
> Date: Thu, 28 May 2009 15:57:02 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages
> 
> On Thu, 2009-05-28 at 15:24 +0200, Olaf Wagner wrote:
> > All bin packages are pre-built and can be installed with the
> > included install.sh (which simply executes cm3 -ship multiple times).
> 
> As I said, this kind of binary packages are not something Linux people
> want.
> 
> Also, in standard RPM based distro (and most are, except ones which are
> Debian based but they have similar packaging philosophy) we have
> features which make handling of big number of interdependent packages
> easy task. Installation of cvsup on fresh system will pull suplib and
> also package(s) with m3core/libm3/set/parseparams/patternmatching
> libs... Big number of packages or not, it's something RPM (system) will
> do for me.
> 
> I have some (RPM spec file) templates developed which enable making
> packages which contain interdependent packages and once I get content of
> your packages (combined with some free time) I will make spec files with
> same content.
> 
> -- 
> Dragiša Durić <dragisha at m3w.org>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090528/c2182517/attachment-0002.html>