Re: A section for commercial software?
On Monday 21 May 2001 18:55, Mikael Hedin wrote:
> > A .deb unpacking into /opt has no added value to me, it will just help
> > to confuse.
>
> Well, it is managed by apt/dpkg/dselect/whatever, and benefit from
> dependencies etc. That may help 3rd party not to ship their own
> versions of every shared library used (I know matlab did this when I
> used it--why then shared libraries!!?). I think this is value added.
If an application ships with it's own libc6 then obviously it needs to put it
somewhere that it won't conflict with the real copy. If such a broken
application was Debianized then it wouldn't be that difficult to put another
copy of libc6 in /usr/lib/matlab/ and have that added to the start of the
library path by a shell script which runs the main program.
On Monday 21 May 2001 20:35, Steve Greenland wrote:
> > Otherwise nothing would have been won over just distributing as
> > tar-balls.
>
> No, they'd still support dependency stuff, integration with
> apt/dpkg. The benefit of using /opt/foo is that they don't have to worry
> about stepping on files in the main Debian distribution.
>
> I've mixed feelings on this. Part of me argues that the 3rd party
> should grab the Contents file for main and make sure that they don't
> conflict. However, there's no real way for them to register files with
> us, and no way for us to detect conflict with them, which seems unfair.
If the same file name in /usr/bin is provided by two packages then dpkg will
tell you at install time. If the same name is used in /usr/bin and /opt/bin
then the only way you'll notice is when you type the command and something
unexpected happens (if the PATH order doesn't match which command you thought
you were running).
Is this a benefit?
> I find it hard to object to third parties using /opt. Most vendors do
> this for add-on packages for the proprietary Unices, even if they use
> the OS vendor's packaging system. It seems completely consistent with
> the FHS.
For example Solaris package manager has considerably greater support for
changing the root directory of a package installation than dpkg. If/when
dpkg is enhanced to have the same support for this as the Solaris package
manager then Steve's point will carry more weight.
Of course if Steve can provide an example of a proprietary Unix that has as
little support for changing the root for packages as dpkg has which has /opt
used for commercial software then it'll be a more convincing arguement.
On Monday 21 May 2001 21:48, Zed Pobre wrote:
> There are two major benefits to using /opt:
> 2) Exportability. /usr should be NFS-exportable, possibly sans
> /usr/local, without encumbrance. Any software, whether it has
> dpkg information or is packaged in a .deb or not, that has a
> one-license-per-machine type policy MUST NOT contaminate /usr.
>
> The FHS is fully correct in specifying /opt for
> third-party-vendors.
On Solaris commercial applications look to the system ID number which is also
typically the MAC address of the primary network interface. Such commercial
applications would probably use the MAC address of eth0 on a Linux machine if
they have the same restrictions, in which case there would be no problems
exporting them as they would only work on machines with correct license files.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: