The source code available for OpenSolaris is very useful for finding out about the internals of Solaris (together with dtrace and mdb). However, as far as I know there is no way of finding out exactly how the OpenSolaris source code relates to the binaries released as formal update releases of Solaris. I.e. which versions of the source files were compiled to form for example Solaris 10 Update 6 (10/08)?
You may draw some conclusions by looking at change dates, the history comments and bug tickets. And I know that there isn't a 1:1 relation between OpenSolaris and Solaris. But are there any better ways that I havent thought of?
There are not any better ways of that I can think of, to correlate OpenSolaris sources with Solaris 10 binaries. The source tree for Solaris 10 is a separate branch, and features and bug fixes and sometimes back-ported to from the OpenSolaris branch to the Solaris 10 branch.
It will be helpful for you to consider the different consolidations within Solaris. For example, if OpenSolaris has Gnome X.Y and Solaris 10 has Gnome X.Y, then the sources and binaries for Gnome components will be identical. If you are only concerned with the OS/Net part of Solaris and OpenSolaris, then the code is only loosely correlated in general.
Related
I am in need of working with a specific version of the text editor Lyx, the 1.3.3, on a CentOS 7 environment. I found the .rpm package and some sort of source code, but as it's a very old software, many library are obsolete and cannot be found when installing from the rpm file and for some reasons no c++ compiler I used seems to be good to compile the source code.
Now my question: I do have a CentOS virtual machine with this specific version of Lyx installed properly. Is there a way to "clone" or somehow copy it into my CentOS main partition? Or, if this is too barbaric, how can I extract/install from the VM CentOS the libraries I need?
I apologize if my question doesn't make much sense, I am by no means an expert of Linux distros and I might have some misconceptions brought over from Windows.
We have 15 Solaris-10 (Dinosaurs, I know) zones, all of which have a few NFS-mounted file systems. In fact, I have been installing my Perl scripts there so that I need only edit once and it is updated for all 15 zones. We have an opportunity to install Perl-5.20 in a separate directory tree from the Perl-5.8 environment the users are [in their view] locked into. Similarly, they see themselves as locked into gcc 3.3.2, terrified to budge. We have an opportunity to install the latest gcc (including g++, of course) in a similarly alternative directory tree. I guess the idea would be to install the new gcc, then use that to configure and compile Perl.
The problem: Configuring the new Perl and gcc installations in a different directory tree from the default is kinda error-prone. (There are likely another non-default options as well.) To do the same non-standard installations 15 times is SO inviting a screw-up!
My solution (maybe): Install the newer Perl & gcc in a directory on an NFS-mounted file system, like my utilities. Those in the know (the DBAs mainly) would put that directory earlier in $PATH than /usr/local/bin. Those not in the know - said terrified users - would remain blissfully unaware of the much better tools under their noses and never the twain shall meet to be blamed for messing up the environment of the other.
Is this a realistic solution? Are there library dependencies within Perl and gcc that would rule out an NFS installation? Has anyone done this before? (Actually, I think they did this at one place I worked but the always messed the code in the process.)
Thanks much for help here.
-- JS
I recently built gcc 4.9 from source and used it to build Perl 5.18.2 on Solaris 10 on an NFS share without any problems. Our stack of cpan modules installed without issue, including DBD::Oracle.
I've been using RCS (revision control system) from MKS Source Integrity for several old projects. I have to move to a new Windows 7 computer. The old version I have does not install on Windows 7, and a new version of the software is very expensive.
What is the best free or cheep source of RCS for Windows 7? Also, will it be compatible with MKS Toolkit which I am still going to install?
The official website for RCS has Windows 32-bit binaries, but they are dated. YMMV. http://www.cs.purdue.edu/homes/trinkle/RCS/.
Edit: I just tried the binaries (from the first zip file). They seem to work on a trivial text file.
I put them in a directory. Then I created an "RCS" directory. Then I created a text file. Then I ran "set TZ=EST" in my cmd.exe window (the tools require a timezone). Then I was able to check the text file in and out with the RCS command line tools.
Note that large files are probably not supported given the date of the binaries.
If you want the binaries to be available system wide, you have to place them in a location on your Windows PATH and set the TZ environmental variable to the zone you need in your account's environment.
RCS offers reverse merge which can be useful when you want to apply selected fixes for ECO version of your software without addition on less tested product enhancements. I was able to produce ECO version of real-time control system with several hundred fixes without the assistance of software engineers working on the next release of the product. ClearCase did not offer similar capability at the time.
We used rcs and gmake. Build scripts were written in Perl. Each ran on native Windows. I wish the idiots at the software company in Washington would use / instead of \ for file separator.
On Windows 7 64-bit SETUP32.EXE fails "not compatible with the version of Windows you're running"
My workaround:
Copy sintcm32.dll from a 32-bit machine into c:\windows\syswow64.
In Explorer, double-click a .pj file, set description to "MKS Source Integrity Project/Sandbox File" and target to "[network location]\mkssi\mkssi32.exe"
Create start menu shortcuts to "[network location]\mkssi\mkssi32.exe" etc.
Git (MSysGit) works on Windows 7 and is free. There is a learning curve associated with Git, which I think is worth it (for the benefits you get, especially regarding a distributed VCS), but some may disagree. This bundles come with bash and an ssh client (useful synchronization with remote repositories).
EDIT: For RCS specifically, there is an RCS package via Cygwin or an independent package from the Purdue RCS Homepage (the latter says "The latest PC (OS/2 DOS Win95 NT)", but I guess it might work on Windows 7, I'm fairly sure the Cygwin package works on Win 7).
Whenever I work on a system of any flavor that has a particular way of handling package management, I try to stick with that standard for managing my Perl modules. "When in Rome, etc."
For example, on a Win32 system using ActivePerl, I use PPM for everything and use the great PPM::Make. On a RedHat system I prefer to use RPMs.
Now I am working on a Debian system, and find myself in need of a way to turn an arbitrary CPAN or CPAN style distribution into a deb.
Google shows options like dh-make-perl, CPANPLUS::Dist::Deb and CPAN::Packager::Builder::Deb.
Does anyone with experience with these different tools have any recommendations as to what to use or avoid?
What's the best way to handle building deb files from standard CPAN modules?
Update:
I found an article by Hans Dieter Piercy on this subject - he suggests, for his own needs, CPANPLUS tools. Under some circumstances he recommends dh-make-perl. Jeremiah Foster (who wrote the article brian d foy points to) responds to HDP and makes a case for dh-make-perl.
There's also a post on idimmu.net that describes using dh-make-perl.
ATM, I'm leaning toward dh-make-perl, since that has been thrice recommended (brian d foy as proxy for Jeremy Foster, the idimmu.net author and hillu) vs once for CPANPLUS
dh-make-perl does a good job in taking care of the repetitive and heavy lifting and guessing information from the sources. It has worked correctly for almost all of the CPAN modules that I have packaged up as Debian packages (official or for in-house use only).
That said, the resulting package should only be considered as a starting point for a proper Debian packages. dh-make-perl puts warning notes into the automatically generated such as debian/control (i.e. description of the package and dependencies) and debian/copyright (licensing information).
In response to Manni, I believe that it is a great idea to work with the tools that the OS or distribution provides for package management, not against them. In the case of Debian, this means putting stuff into .deb packages and installing those. Perl's build tools and CPAN do a great job of providing a cross-platform build environment and for distribution of the source code, but compared to package management tools in modern Linux distributions, they perform suboptimally, simply because extra manual intervention is often required that is less easily automated across multiple machines than rolling up a package.
(For one-off and test installations, installing into /usr/local/ and using stow(8) as a poor man's package manager may be okay.)
Even if you are just building the packages for your own use, consider contacting the Debian Perl Group and have someone sponsor an upload to Debian if you feel that the module in question is of use for other people.
I suggest you ask the Debian Perl Maintainers group, rather than here on SO. Just mail the address shown as maintainer on any odd package:
Debian Perl Group <pkg-perl-maintainers#lists.alioth.debian.org>
Back in the day, I added a few modules to Debian, and just 'did it by hand'. I still maintain some. That isn't hard either. but the group now maintains way more package, and has tools.
Jeremiah Foster published an article about turning Perl distros into Debian packages in the Spring 2009 issue of The Perl Review.
There is a very good step by step here as well. (also with links to other good resources and some decent comments. [it is dated 2005, but still mostly relavent and many comments much more recent])
http://www.debian-administration.org/articles/78
here is the debian perl policy (also linked to in article)
http://www.debian.org/doc/packaging-manuals/perl-policy/
You won't like this, but I really think that you should not do this at all. The various Perl Debian packages aren't for developers that need certain Perl modules on their machines. They were built because other applications need them and users want or might want those applications.
Please take a look at the answers to this question before doing something that you probably should not be doing.
I’m using the gcc in MinGW that comes with Strawberry Perl, on Windows XP. I’d like to have ddd (the Data Display Debugger) as well but apparently on Windows the simplest way to get ddd is by running Cygwin. So what's the bare minimum of Cygwin I can install to get ddd up and running? I'd prefer if I could run ddd natively on Win32 but that doesn't seem to be an option.
As far as I can tell so far, only the following (with Cygwin DLL release version 1.5.25-15), and allowing setup to install any other packages to meet dependencies.
Base: base-files, grep
Develop: ddd, gdb
Math: gnuplot
Example to get grep working: Just drop the following files from a cygwin bin directory into an appropriate directory...
cyggcc_s-1.dll
cygiconv-2.dll
cygintl-8.dll
cygpcre-0.dll
cygwin1.dll
grep.exe
The Cygwin setup.exe installer resolves dependencies for you. Just run the installer, find and enable ddd, and click Next. It might install some packages you doun't strictly need, but figuring out which ones you can safely omit is probably a waste of time.
Disclaimer: I haven't tried this; I just install eveything.
If you're going for minimalism, you might want a smaller X server than cygwin-x11 (though it's what I use, and I'm quite fond of it). Starwin X-Win32 is actively maintained (though it costs $$ beyond the trial period), and avoids the overhead of installing Cygwin proper; there are other, zero-cost minimal X servers for win32 available, but I don't have linkage immediately available.
As the documentation at x.cygwin.com indicates, the xorg-x11-base package is the bare minimum needed.