Note: opencsw uses pkgget (same, different from what blastwave used
*before* the messy "divorce" at Blastwave between Dennis Clarke and
Phillip Brown (went and started opencsw.org), whereas Clarke-and-team
created "pkgutil" (pkg-util?).
Now I see on opencsw that THEY have a "pkgutil" too -- plus a 2nd one,
"enhanced" or "advanced" or something.
Whether these various programs (pkg-get, pkgutil, -advanced) are
compatible or not, I have no idea.
I do know that opencsw ALSO uses /opt/csw, the SAME place Blastwave
uses!
So the obvious question: can I get an A from Blastwave and a B
from opencsw, and not break something?
More to the point, can I get an emacs-21 from Blastwave and an
emacs-23 from csw? (presumably new libraries from GNU never
invalidate old functions!)
Sure would have been nicer (or would it?) if opencsw would
have used eg /opt/opencsw instead of /opt/csw!
Any discussion?
Any EXPERIENCE of mixing the two software batches?
THANKS!
David
I would expect breakage.
>Sure would have been nicer (or would it?) if opencsw would
>have used eg /opt/opencsw instead of /opt/csw!
CSW was the assigned Solaris package prefix and csw was the assigned
directory for community software projects.
There can be many community software projects, but a user should
choose one.
I know of OpenCSW.ORG and Blastwave, but I wouldn't be surprised
if there weren't others for niche communities, such as governments
or militaries.
John
groe...@acm.org
Err.. why would you want to?
(seriously, I'm presuming you have a reason, and I'd like to know the
answer)
ditch all that crap
just use sunfreeware.com
Blastwave has lots of stuff, and so do you, but there's
differences in versions, depending on who updated program
x first.
So I (and I guess most users too) would like to have some
from you, and some from blastwave, depending on the versions.
Makes sense to me.
But do tell me ((with repetition) I am able to learn) where
I'm wrong.
Thanks, Phil,
David
Well, last time I looked, they had many fewer packages.
(Now, maybe Sun has thrown a few million at it, and it's
all different now.)
---
What do OTHER people find, between sunfreeware, blastwave,
and opencsw?
Thanks,
David
Assuming you're attempting to use CSW packages as dependencies
for your SageMath builds, set up two zones: one with pkg_get pointing
towards OpenCSW and another pointing towards Blastwave.
John
groe...@acm.org
last time I looked at blastwave, the entire site was gone. I don't trust
such gooofy projects.
I can't say that sunfreeware is really all that high quality either.
There's lots of buggy junk in there, and of course they never document how
they make the packages. You never can tell what stupid options were added
to anything when it was built.
> (Now, maybe Sun has thrown a few million at it, and it's
> all different now.)
>
> ---
>
> What do OTHER people find, between sunfreeware, blastwave,
> and opencsw?
I don't mind sunfreeware of stuff that's too hard to break. They seem to
make mostly functional GNU packages. Let's be honest, compiling the gnu
compiler is a serious PITA.
anything else will be configured with --with-all --and-more-stupid-shit
--with-kitchen-sink --with-PCX --with-lotus-notes or who knows what.
For important stuff, packages here get made in-house. Then nobody has to
install half the entire package website to get something to work, and
upgrades are guaranteed to work and you don't have to have everything
requiring openldap or other irrelevant stuff.
OK, sort of neat, good use of zones.
(Gives me a reason to go study zones!)
But if in general yoiu want to run emacs, sometimes emacs-new,
and sometimes emacs-alpha, regardless of the zone you might
be in -- what then?
Thanks!
David
Well, that was a LONG time ago. Had to do with that "divorce" between
Dennis Clarke and Phil Brown (who split away from Blastwave, and soon
started his own site, opencsw).
But within 10 days or so, Dennis had repaired the damage caused
during the "divorce" process, and has been there ever since.
>
>I can't say that sunfreeware is really all that high quality either.
>There's lots of buggy junk in there, and of course they never document how
>they make the packages. You never can tell what stupid options were added
>to anything when it was built.
>
>> (Now, maybe Sun has thrown a few million at it, and it's
>> all different now.)
>>
>> ---
>>
>> What do OTHER people find, between sunfreeware, blastwave,
>> and opencsw?
>
>I don't mind sunfreeware of stuff that's too hard to break. They seem to
>make mostly functional GNU packages. Let's be honest, compiling the gnu
>compiler is a serious PITA.
>
>anything else will be configured with --with-all --and-more-stupid-shit
>--with-kitchen-sink --with-PCX --with-lotus-notes or who knows what.
>
>For important stuff, packages here get made in-house. Then nobody has to
>install half the entire package website to get something to work, and
>upgrades are guaranteed to work and you don't have to have everything
>requiring openldap or other irrelevant stuff.
>
>
Well, that's one approach, but a lot more work for you.
(But you keep your job!)
David
> last time I looked at blastwave, the entire site was gone. I don't
> trust such gooofy projects.
the major packagers forked of from blastwave to opencsw. So the people
that run blastwave before are now running opencsw. Just use opencsw and
you're good to go.
Thomas
If you were my developer, I would tell you to do your development
on your (stationary or mobile) developer workstation and do your
builds against your SageMath subversion or GIT checkouts on your
OpenCSW and Blastwave build zones.
I would ask you if Sun's versions of GNU emacs and SunStudio XEmacs
that ship for Indiana and Nevada are suffient for your developer
workstation.
John
groe...@acm.org
On Dec 14, 11:18 am, dkco...@panix.com (David Combs) wrote:
> ....
> Note: opencsw uses pkgget (same, different from what blastwave used
> *before* the messy "divorce" at Blastwave between Dennis Clarke and
> Phillip Brown (went and started opencsw.org),
That paragraph has a very misleading implication.
Better and more appropriately written as
"Philip Brown (started CSW packaging, wrote pkg-get, moved both to
opencsw.org)"
and...
> whereas Clarke-and-team created "pkgutil" (pkg-util?).
no, "Clarke-and-team" did NOT create pkgutil. Just like he did not
create CSW packaging. I did. he merely hosted it.
"Clarke" does not own pkgutil, nor did he have much to do with the
creation of it.
It was primarily created by (and is still owned and maintained by)
Peter Bonivart.
Who has contributed effort to both blastwave, and opencsw.org.
For those who care, pkgutil works on both repositories, as does pkg-
get.
yes.. but you didnt answer my question.
Why would you deliberately want to keep the older version of emacs
around?
You used it as a 'specific' example, of a need you have.
Was it merely a hypothetical example after all, and you have no actual
*need* to do so?
> So I (and I guess most users too) would like to have some
> from you, and some from blastwave, depending on the versions.
>
> Makes sense to me.
Not to me... You havent said WHY you want would older versions from
blastwave.
Please give specific cases, rather than vague hypotheticals?
It's two steps of keeping the job. One is keeping busy and two is not
using bogus software from some site that went away after people started to
fight over a domain name.
It's nonense like that that makes management really question the usage of
"free" software in a business environment, which is too bad as quite a bit
of it is really good stuff.
I can't imagine telling anybody that "sorry, I can't make that app server
because I can't find the installers for the version of [whatever package]
we used last time, let's just try some other random version and hope it
behaves 100% the same as the existing systems we're running".
I suppose I'd like to keep the old one until I'm sure the new
one is ok. But I can live without that, for sure.
It's just that there's tons of other blastwave software there,
including libraries that emacs might use.
And everyone else in this thread gives their opinion
that you're asking for trouble if you mix stuff from
both sources (you and blastwave) in the same directory,
ie /opt/csw/...
You know, assuming disk has gotten sufficiently cheap,
you could have a parallel opencsw that has all the
same stuff, but compiled etc to work in opencsw.
Then one could easily have stuff from both places,
both being on the PATH.
I don't know... it just seems a pity that with
each of the two sites working so hard, that the
user cannot use them both. I mean, all the work
that each of the two is doing is for presumably one
purpose -- to provide software, already compiled, etc,
to solaris users. I mean, the more users a site
gets, the happier the people who put in all the work.
No way to give feedback (positive) to the group
one's NOT allowed to use, because the decision to
provide only a single place to store the stuff
-- the stuff from ONE of the two sites.
To the extent any anger is involved in the decision
to use /opt/csw, seems to me, gets in the way of
providing services to the Solaris user base.
----
Anyway, looks like I'm getting nowhere here,
so if I want a newer emacs than is on blastwave,
I'll have to grab the sources and build it
myself. :-(
David
>
>It's two steps of keeping the job. One is keeping busy and two is not
>using bogus software from some site that went away after people started to
>fight over a domain name.
>
>It's nonense like that that makes management really question the usage of
>"free" software in a business environment, which is too bad as quite a bit
>of it is really good stuff.
>
>I can't imagine telling anybody that "sorry, I can't make that app server
>because I can't find the installers for the version of [whatever package]
>we used last time, let's just try some other random version and hope it
>behaves 100% the same as the existing systems we're running".
Yes, seems too bad that when the split happened,
the two of them couldn't work out a scheme
where the Solaris user could grab stuff from
either site. With the indended beneficiary actually
losing benefit: before the split-up, user would
get the benefit of let's call it 2x people's efforts,
whereas after the split, a user can benefit
from the gladly-performed work of x people -- user
has to choose ONE of the teams, and stick with
that. Period!
That's my take of the situation, anyway.
David
Well, thanks for that last, that each of them work the
same on each site.
David
Competing CSW package projects should yield happier
CSW package users.
>Anyway, looks like I'm getting nowhere here,
>so if I want a newer emacs than is on blastwave,
>I'll have to grab the sources and build it
>myself. :-(
You might consider volunteering to maintain GNU emacs
for Blastwave if the current maintainer has moved on.
John
groe...@acm.org
There are a lot of people "working hard", for both debian linux, and
redhat linux.
They are both "linux".
Does that mean if you somehow install both in parallel on the same
running OS, that you get improved benefit from running one of them? I
dont think so.
The sane thing to do, is pick the one that best suits your needs, and
go with it, rather than try to cobble them together.
> Anyway, looks like I'm getting nowhere here,
> so if I want a newer emacs than is on blastwave,
> I'll have to grab the sources and build it
> myself. :-(
Or just switch over to using opencsw packages.
Which should be almost as simple as editing your pkgutil or pkg-get
config to point to an opencsw repository, and using the "upgrade"
command :-)
> Anyway, looks like I'm getting nowhere here,
> so if I want a newer emacs than is on blastwave,
> I'll have to grab the sources and build it
> myself. :-(
>
>
> David
I often configure software from source. Read the readme and the configure
options and you often find that there is some advantage to some options in your
particular situation.
I do not expect Emacs has a ton of dependancies, so it should not be too hard.
Personally I only ever use vi.
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
Well, though Phill is "plugging" his own site here, he is correct in
one thing; I've used the upgrade option earlier in the year when we
had to make the decision of who to go with, Blastwave or OpenCSW. We
(I), chose to move our platforms to OpenCSW and the upgrade worked
perfect. All the old Blastwave software we had installed (too much or
not) all upgraded just fine. We primarily use SAMP stuff (minus the
MySQL), but it's nice to have those little tools at the ready if
needed.
As a sidebar (but my objective here) I was wondering when Apache2 will
be upgraded on OpenCSW. I see the "Jones" have already update
theirs. {:-) And I'm not mixing the two! I picked my poison.
I use to compile all my own, but in the early days of Solaris 9 (I
think), it was getting to be a real pain since many developers
(Linux), never considered Solaris, so there were always little things
wrong here and there. If only I had the time to fuss with all that
stuff these days. I have less-fun things to worry about. LOL
Besides, when I finally die at my desk with eggnog in-hand and before
the body is even cold the "young-guyz" will be screaming, hooray, the
witch is dead, break out the RedHat boys. Hee, hee. I should change
my handle to something like, old-cranky-dino. Damn I wish we could
have Gmail aliases.
Happy Compiling .... (and Holidays).
Have you played with Sun's webstack for Solaris 10?
<URL:http://www.sun.com/software/webstack/>
John
groe...@acm.org
:-)
We're working on it!
We first wanted to get an updated, shared libapr out., to build it on
top of.
That particular package is being worked on as we speak. candidate
build had a minor bug in it, so was tossed back to the maintainer to
fix before release.
> Well, though Phill is "plugging" his own site here, he is correct in
> one thing; I've used the upgrade option earlier in the year when we
> had to make the decision of who to go with, Blastwave or OpenCSW. We
> (I), chose to move our platforms to OpenCSW and the upgrade worked
> perfect. All the old Blastwave software we had installed (too much or
> not) all upgraded just fine. We primarily use SAMP stuff (minus the
> MySQL), but it's nice to have those little tools at the ready if
> needed.
PS: a little tip, if someone's upgrade gets a little complicated....
or you just want to "clean things up" first:
(or you want to cleanly copy a set of CSW packages from one machine to
another...)
pkg-get -l
will give you a list of your installed packages based on the "software
name".
eg:
$ pkg-get -l
amavisd_new
ap2_modfastcgi
ap2_prefork
ap2_worker
....
You can save that to a file. then loop through pkgrm'ing all CSW
files.
Once the machine is "clean", adjust your pkg-get.conf to use the
appropriate url, and then do
pkg-get -i `cat outputfile`
and it will walk through adding the software, "fresh".
The nice thing about this is that it gives you a chance to review and
edit the outputfile, before adding all the junk back in.
Great tip Phill, thanks! And thanks for the update on the upcoming
apache2 release via OpenCSW.
Chris
Phil -- could you be a bit more specific about the precise changes
one has to make to the current blastwave pkgutil to access opencsw
stuff?
Another question: by playing with a symlink, defining it one
way when wanting to deal with blastwave, and a second way
when dealing with opencsw -- any way something like that
could enable a system to have both available.
I suppose when you wanted to USE a package, or a set of packages,
you would have to use packages from only one or the other --
else internal refs would be to the wrong place?
I really resist the idea that a user must 100% toss one of the
two sites as a source of pre-built software.
I know you two guys are angry at each other, but what you've
done by choosing the csw directory-name seems makes me think
of a High Noon type duel, where one participant never wanted
to be out there in this only-one-will-walk-away-alive situation.
I look at the opencsw site, and am impressed with all that
you have done there, coming out with a rather nice product.
But perhaps you're taking your how-to-succeed-in-business
method from, say, Microsoft (or maybe IBM (of old) or Intel --
heck, for those of a certain age, AT&T!, "you want to
use our system -- you cannot hook any other manufacturer's
equipment than ours -- and if you don't like it, tough!).
(parens wrong, sentence structure too -- but you get the
gist of my point.)
We are all -- at least us users -- better off were, say,
Ford and GM, etc, to make their cars such that a piece
of equipment from one would work on the other.
Disk being cheap enough, maybe two versions, csw and, well,
opencsw.
Or even some kind of a perl or sed filter we can run a
opencsw package through and change every csw to opencsw?
Surely there's SOME way we can take advantage of both efforts!
Hey -- thanks for reading this thing!
David
You might be confusing two Dave's there.
sure, there's multiple ways.
Just go edit whatever line you changed to set your choice of blastwave
repository, and change it to point to an opencsw one.
Or use commandline flags for one-time use. Dunno about pkgutil, but
pkg-get uses
pkg-get -s url://goes/here.
>
> Another question: by playing with a symlink, defining it one
> way when wanting to deal with blastwave, and a second way
> when dealing with opencsw -- any way something like that
> could enable a system to have both available.
>
> I suppose when you wanted to USE a package, or a set of packages,
> you would have to use packages from only one or the other --
> else internal refs would be to the wrong place?
Yeah, it would be ugly. because of dynamic library runpaths. which
will want to use /opt/csw.
ERRRR.. i SUPPOSE you could manually override with LD_LIBRARY_PATH.
strongly unrecommended.
However, there is also the issue that many programs expect to find
configurations under /opt/csw also.
You'd have to re-symlink, or re-loopback-mount, /opt/csw, every time
you wanted to change repository.
Or use chroots.
Or zones.
> Or even some kind of a perl or sed filter we can run a
> opencsw package through and change every csw to opencsw?
There is no easy way to do that, i'm afraid, because of the need for
binary editing.
if you wanted to do it the HARD way and rig something up, you might
potentially work it, if you wanted to have an alt dir with exactly the
same length. so, "/opt/csw", and "/opt/CSW" perhaps,... and then you
could substitute all occurrences relatively safely.
But you're really better off by looking at your needs, and seeing
which organization meets your needs better.
Hypothetical example of method you might use to make your choice:
Lets say that you need 3 programs; progA, progB, progC.
both sites have progA up to date
site1 has progB newer, and you want the newer.
site2 has progC newer, and you want the newer.
So, contact site1, and say, "hey how about an update to progB?"
also, contact site2, and say, "hey how about an update to progC?"
Go with whichever one gives you the update faster/better :-)
>We are all -- at least us users -- better off were, say,
>Ford and GM, etc, to make their cars such that a piece
>of equipment from one would work on the other.
Eh... only because that means shared parts are "cheaper" for you to
buy. But in this case, both are "free", so ... :-)
(and in some respects, users have been worse off with shared parts in
cars: "Both Suck!" :-D )