Maciej (Matchek) Blizi??ski <[email protected]> wrote:
> > SchilliX would need separate and slightly different packages but they could
> > be
> > compiled from the same set of sources.
>
> Sounds good.
>
> > The packages should be as compatible as possible to the previous Sun
> > packages.
> >
> > This means that we need to install the binaries relatively to / /usr or
> > /usr/sfw
> > and that there is a need to have ELF version information in libraries that
> > are
> > compatiblle to the Sun version data.
> >
> > The related information can be either obtained from the mapfiles from the
> > sfw
> > source consolidation or from readin the libraries itself.
>
> Although generally the BUILD_PREFIX can be set to something else,
> there are many places where the "/opt/csw" prefix is hardcoded: for
> example in patches, and in shipped example config files. I think that
> if you plan to adapt the sources to make the libraries backward
> compatible with the SFW packages, changing the compiler is probably
> the least of your worries.
Then we would need to forbid such patches that introduce harcoded strings like
"/opt/csw".
If there is really a need to have such strings in the code, they should be
"introduced" via defines from the cc command line like:
cc '-DMY_STRING="/some/path"'
and thus could be passed as parameters to the build system.
> It would be cool if there was source-level collaboration. Making the
> same sources build in two flavors would be a challenge, a very
> interesting one.
I would be interested in getting compiled SVr4 packages for SchilliX as there
is already a lot of effort directly related to OpenSolaris and the ON code.
Jörg
--
EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
