----- Original Message -----
From: Ian Collins <[EMAIL PROTECTED]>
> Moinak Ghosh wrote:
>
> >>
> >
> > I have been pointing this out for a while. Right now all the
> > dependencies are based
> > on package names which fosters duplication. Instead we need to
> have
> > dependencies
> > based on standard exported (by some means) module names.
> >
> OK, maybe a starting point would be to agree on a package naming
> convention. I know this won't be easy, if you look back though the
> archives of the SolarisX86 Yahoo list, you will see how much
> wrangling
> went on before the CSW name was agreed for Blastwave packages.
> Mind
> you, much of that related to the directory name.
>
> Any suggestions an how an agreement could be reached? Could it
> work
> with just the package name being common and still having SFW, CSW,
> SUNW
> etc. packages? I don't see why not.
It is possible, but that implies that package contents must also be
uniform. One repository may deliver two related modules in separate
packages while another one delivers them as one - this will break
the scheme. It is much harder to get agreement on uniform package
contents.
IMHO it is bettter to separate the package namespace and the
dependency namespace. It also allows for fine-grained dependencies.
>
> >
> > Another wild idea it to use something like a stripped down
> configure
> > script to check
> > for dependencies. This will not require standard module naming.
>
>
> Wouldn't that require consistent library names and version
> numbering?
> Or maybe something like what(1) could be used (is there an
> equivalent
> for CVS files?)?
This already works with the current configure scripts distributed
with most software now-a-days. And library names will be
consistent - if you use OpenSSL on X platform you can always
expect to find libssl and libcrypto. Only the version may differ
and that is what the dependency check also has to verify
(whether the package version requirements are met).
Essentially instead of a fixed policy the dependency check is a
script that checks the paths to verify whether the required software
is present. This offers maximum flexibility and interoperability with
software installed from various repositories, but is more difficult to
implement.
Regards,
Moinak.
>
> Ian
>
> >
>
> _______________________________________________
> opensolaris-discuss mailing list
> [email protected]
>
_______________________________________________
opensolaris-discuss mailing list
[email protected]