Laszlo Peter wrote:
Hi Rod,
Thanks for the detailed response.
Of course I agree that it's better to avoid the problem by
carefully controlling public interface changes. However more
and more software in Solaris comes from external sources ...
So we can't break the interfaces we'd shipped
Hi Rod,
Thanks for the detailed response.
Of course I agree that it's better to avoid the problem by
carefully controlling public interface changes. However more
and more software in Solaris comes from external sources
and while we can work with community maintainers and try
and make sure they
Laca wrote:
As far as I understand, the main problem with multiple versions
(apart from the increased maintenance effort) is that different
versions of the same lib may end up linked to the same executable
(through dependent libs) and it'll cause unpredictable runtime
linking and most likely a
Ferdinand O. Tempel wrote:
for Debian packages to work, you need to adopt the
entire Debian way of thinking.
Bells and whistles and all.
But it'll be a fight against both the OpenSolaris
community and
What are the core differences WRT the way Sun has
traditionally done
sfw and the
Darren Kenny [EMAIL PROTECTED] wrote:
A Debian distro based on Open Solaris is a perfectly valid idea, and for
some people would be perfect for them - this is exactly why people like
RedHat and Novell/SuSE have the concept of an enterprise distro and a
Fedora Core or Novell Linux Desktop -
when I want to install libbonobo as a dependency for
another package, I want just that and one copy on my
system, and let every package that needs it find it.
company ticker appended to package names is one
ridiculous idea, when a simple package name would do
just fine. All, pkg-get would
Don't expect things to work if you adopt to the entire Debian way of
thinking.
Actually, I do. I don't care much about what the debian project thinks or
expects, and I doubt it's what you claim as:
As long as Debian compiles software on Linux-2.4 and
expects the resulting binaries to work on
Did you ever consider that one possible reason is
that Solaris X86
simply doesn't have all the drivers - I have a
laptop, and it's less
than 2 years old, which Solaris will install on, but
there simply are no
network drivers for it. So it would take much more of
my time to get to
a
Wouldn't it be even better to not have to make that
judgment call? Now
don't get me wrong, the stuff done by the likes of
Blastwave and
Sunfreeware were *hugely* important - I'd just like
to see us acting as
a combined community, working on porting the
software, integrating the
software
Ferdinand O. Tempel [EMAIL PROTECTED] wrote:
Don't expect things to work if you adopt to the entire Debian way of
thinking.
Actually, I do. I don't care much about what the debian project thinks or
expects, and I doubt it's what you claim as:
As long as Debian compiles software on
--- Glynn Foster [EMAIL PROTECTED] wrote:
Hey,
Yes, of course it would have been better!
We have clearly identified an area where there
things could improve,
but that's not the main problem.
The main problem is that people who converted are
trying to push what
they're used to
On 7/21/05, UNIX admin [EMAIL PROTECTED] wrote:
This is the exact same approach that Linux takes. The only way to patch a
software subsystem through the OS interfaces is to do `rpm -u` which goes and
[I]replaces the entire software subsystem[/I] in order to update it.
This is very much
Joerg Schilling wrote:
Don't expect things to work if you adopt to the
e entire Debian way
of thinking.
As long as Debian compiles software on Linux-2.4
4 and expects the
resulting binaries to work on Linux-2.2, the did
d not yet grok how to
deal with evolvoing interfaces.
Which is a bad thing why? (Please don't say space.)
if you can prove duplication is a good thing, I will be happy.
anyway, its bad because it:
1. wastes network bandwidth for downloading packages which are already
installed, working, used, tested.
2. wastes time re-installing the packages
One of the core values of Solaris is that sharable things really
should be shared.
This begs the related questions of
What constraints does this place on the shared component, and
What do you do when the shared thing evolves
Sun has a proactive development methodology that looks
Interesting as I'm seeing this in the kde 3.4.1 from
m blastwave.
Multiple copies of different versions of libstdc++
compiled
into some of the daemon process. I wonder if this is
what is causing
it to crash.
if 'ldd' shows both .5 and .6 referenced, it will lead to trouble sooner than
Hi John,
On Wed, 2005-07-20 at 19:31, John Plocher wrote:
Without this ability to manage the evolution of shared components,
it becomes extremely difficult to reuse them, because asynchronous
development almost guarantees that a change to the shared component
will break a consumer, and that
17 matches
Mail list logo
