Peter Tribble wrote:
On Mon, 2006-05-15 at 20:56, Roman Bekker wrote:
Rich Teer wrote:
On Mon, 15 May 2006, Roman Bekker wrote:
2. In addition to packages, my idea is to have a tree of /usr/ports on
OpenSolaris, like we have on FreeBSD, NetBSD and OpenBSD, with links to
places where an user can automatically download, patch for clean compile on
OpenSolaris, build, verify and install any piece of open-source software that
can be adopted, ported or patched to work on OpenSolaris. By just typing 'make
install' in the /usr/ports/subdir_of_needed_software.
I like the idea, but not the use of /usr/ports. How about /opt/ports?
I have no problems with the idea to have it under /opt, so if you would
like to see the ports collection in /opt/ports better, I agree :)
Heck no.
/opt - optional 3rd-party applications
/usr - core components of the OS
I agree with that view. I, personally, also think that it is more
logical to have ports collection residing under /usr/ports, than
/opt/ports.
But I care more about the idea itself than about where would the ports
tree reside.. So if there will be many people who'll object or refuse to
have it under /usr, I have no problems with it residing under /opt... :)
I thought you wanted something fully integrated as part of
the OS, in which case /usr/ports is right.
Yes, that was what I wanted. But, while I see /usr/ports as a fully
integrated part of the system, it is also optional. I mean, you can
choose to install the ports tree or not. And also, even if you have
installed the ports collection, you can decide to use or not to use it
for software installation (as you can still use binary packages).
That's the way it works on *BSD :-)
(I still can't understand why /opt isn't empty after I install
Solaris off the install CDs. It's getting there, but it's
not quite clean yet, with a few symlinks presumably stuck
in there for compatibility. Mind you, why is onbld in /opt?)
Same here. I'd like to see /opt clean after initial Solaris installation.
You're proposing a pure source repository, right?
Not exactly that. In fact, on *BSD systems the ports collection is more
than "pure source repository" - there ARE some binary packages, like
Opera. And you can just go to /usr/ports/www/opera and type 'make
install', and it'll download all libraries needed to run Opera
(including Qt), if they are not present in the user's system already.
Then it will configure and compile these libs, package and verify them,
and finally install them. Only then it'll download, package, verify and
install Opera itself. That's the way it works.
But mostly you are right - most of the software in ports collection is
provided in the open-source form.
How would this interact with a binary repository such
as might be provided to install Solaris components over
the net?
Ports collection would be a separate repository, so it wouldn't mess or
badly interact with a binary repository.
But the ports collection would contain all (or almost all) the same
packages which are there in the binary repository. Plus, I think, some
more packages (as we see in FreeBSD, where the ports collection offers
much more software than the binary precompiled package collection).
It is easier to add something new to ports, than to binary packages,
since the ports collection needs just some makefiles, patches, scripts
to provide 'cleanly compiling on OpenSol' version of software XX.
And binary package for the XX software needs to be tested on different
builds of OpenSol, different configurations, etc. The port (as opposed
to binary package) would compile on the user's target machine instead.
Thus the port would allow more flexibility and configuration options,
but at the cost of the download/compile/package/verify time (so it'd be
easier for newbies to install binary packages, I think).
Often the ports collection contain newer versions of the software than
is provided in precompiled binaries. For this same reason. And, after
several days, weeks or months (depending on package maintainer's speed
of reaction :-), there usually is a precompiled binary package in a
binary repository :) But at the same time there is again a new version
in /usr/ports :)
That's the way it works on BSD, and that's what I think would be
beneficial to have on OpenSolaris.
Or with any other 3rd-party repositories (which
might be able to provide prerequisites)?
There's no problem to integrate any 3rd part software to ports
collection. See how it works with NVidia drivers, for example: the end
user comes to the /usr/ports/graphics/nvidia-glx, types 'make install',
and the port automatically downloads the latest version of NVidia
graphics drivers from the NVidia's ftp site, configures them, compiles
the kernel module, packages the driver, verifies the package and
installs it.
And things are done then: user does not need to go to the NVidia site,
to download the driver manually, to invoke its installer or compile its
kernel module manually etc :)
Would the user have a choice between binary download
and a build from source?
Surely he would. That's what we see on BSD: if you want something that
may be somewhat old, but what is already precompiled, patched, packaged
and verified and what is considered stable (or relatively stable), you
just install a binary precompiled package. Also if you want quick and
easy way with no configuration, no compilation - use binary packages.
But then, if you want something all fresh and new, which is currently
(temporarily?) absent in binary form, or if you want more flexibility
and you want to configure the software XX with options X, Y and Z, while
the binary was compiled with only feature Z :) You go to the
/usr/ports/software_you_need, and issue a 'make install' command. That's
all :) Or if you, for some reason, need a bit old software, which for
some reason isn't available in the binary form, you can also find it
under /usr/ports/an_old_piece_of_soft - and compile and install it.
Surely, you can do the same manually, going to the author's site,
downloading the sources, configuring, compiling and installing it.
Without using /usr/ports. But it is MUCH more pain in the ass, because
there is NO guarantee that the software would compile cleanly on
OpenSolaris, if the author didn't provide an explicit support for it.
With the ports collection, it's easier to compile a piece of software,
bcz the port already contains all needed patches to provide
compatibility and clean compilation on OpenSolaris (like is done on BSD
systems).
Would the source repository include components (possibly
different versions, or even the same versions) that are
available from the binary repository or bundled with
the OS?
The source repository (the ports collection) would include the same
components that are available from the binary repository (with the same
versions). PLUS some more components, PLUS newer versions that aren't as
yet available in binary form, PLUS older versions, that weren't for some
reason precompiled and thus aren't available in the binary repo.
So the user has the choice: if he goes to /usr/ports/irc/xchat, he gets
xchat-1.8, if he goes to /usr/ports/irc/xchat2, he gets xchat 2.6.2.
That's how the FreeBSD ports work. And yes, he CAN have several
different versions of the same software installed, if there is no
logical conflict, bcz the ports collection installs versioned binaries
and libs (xchat-1.8 and xchat-2.6 in this example). And if there is a
conflict and user CAN'T install another version, the correctly written
port's makefile would tell user about the problem and wouldn't install
anything, and would offer him to 'make deinstall' and 'make reinstall'
instead :)
And he can do that deinstall/reinstall or decide not to touch anything.
Could the user select from several different versions?
Yes.
In the event that different repositories might develop,
would the user be able to choose between repositories?
Yes. That's what we have in BSD ports - you can set (with editing some
config files) from where to download the ports collection itself, and
from where to download the individual port's distribution files
(distfiles). More than that, BSD ports automatically use mirrors :)
Where would the software itself end up being installed?
In FreeBSD, the software compiled from ports goes to where it should
reside in the system if it was installed from binary package with the
same name, or where it would be installed if you'll compile it on your
own (./configure, make, make install) with default options to configure.
Say, the X Window compiled from ports system would install itself in
/usr/X11R6, 'sh' would go to /bin/sh, etc.
But most of the software which is in /usr/ports, installs itself in
/usr/local.
On OpenSolaris, if we want to make the /usr/ports a nicely integrated
part of the system, it should follow the same logic. It should not
behave _exactly_ like ports on FreeBSD, but behave as expected on
OpenSolaris, and install the software to its normal place on OpenSolaris
(not to where it is normal to see installed on Linux or BSD :) And, to
prevent any potential conflicts with existing utilities, it is wise to
install most of this software under /usr/local. Only when it is
reasonable, should it be installed in, say, /usr or elsewhere it
naturally resides (as is in cases with X11 and /bin/sh).
And also, the port should not only configure and compile a software XX
and install it in a manner like you can ./configure && make && make
install. It should invoke something like pkg_build to build a custom
user's binary package, then to verify the package's integrity and to
install it invoking pkg_add. That way the software you've installed from
ports, is registered in system-wide package database the same way like
you've installed it from precompiled binary. Again, that is what the
FreeBSD ports system does :)
(And how do you make sure it doesn't trample over something
else that's already been installed?)
The correctly written port's makefile should always check for confilcts
with packages that are already installed on target system. And if there
is any conflict - DO NOT do anything. Issue a build error and tell user
about the conflict, and offer him to 'make deinstall' and then 'make
reinstall', if he wants. But do not invoke these commands. Just tell
user to do so, if - and only if - he really wants.
Also the software in ports collection should:
1. Be versioned.
2. Install itself by the way of self-packaging and registering in
system-wide package database, just like binary packages do. The only
difference is that these were precompiled, and the port is compiled and
packaged on user's machine.
With best regards,
Roman Bekker.
_______________________________________________
opensolaris-discuss mailing list
[email protected]
