On Thu, Sep 23, 1999 at 11:55:09AM -0700, Chris Waters wrote:
> And in any case, I meant wrong in the moral sense, not the legal
> sense.
I don't see that that's a meaningful distinction for this case.
--
Raul
Raul Miller <[EMAIL PROTECTED]> writes:
> You don't get to call the FHS wrong without providing a rationale
Sure I do -- it's one of the benefits of living in the US of A. :-)
But in any case, I'm not calling the FHS wrong, I'm calling the actual
*use* of /opt wrong. FHS doesn't require that u
On Thu, Sep 23, 1999 at 11:28:45AM +0100, Philip Hands wrote:
> Andreas Voegele <[EMAIL PROTECTED]> writes:
> > Firstly, none of the existing applications that go to /opt use these
> > directories. For example, the version of Applixware that SuSE ships
> > goes to /opt/applix and is started with /
On Thu, Sep 23, 1999 at 03:03:52PM +0100, Philip Hands wrote:
> I think we should create /opt because the FHS requires it, and
> possibly /opt/README.debian if the FHS allows it, but nothing more.
FHS doesn't allow us to create /opt/README.debian, at least not
without getting the sysadmin to be in
On Thu, Sep 23, 1999 at 11:24:37AM +0100, Philip Hands wrote:
> It strikes me that if all the distributions include these directories
> by default, that ISV installer writers will put stuff like:
>
> for i in $PACKAGE_DIR/bin/* ; do ln -s $i /opt/bin ; done
>
> in their install scripts. This i
On Thu, Sep 23, 1999 at 10:19:04AM +0200, Andreas Voegele wrote:
> You suggest creating the following directories by default:
>
> /etc/opt, /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib,
> /opt/man and /var/opt.
Yes.
> Firstly, none of the existing applications that go to /opt use these
Bart Schuller <[EMAIL PROTECTED]> writes:
> I'm going to take over gnome-print from Vincent and I was wondering
> whether to convert it into a proper libgnomeprint2 and -dev
> package. The package is quite small.
We've got separate packages for a lot of small libraries in
gnome---libzvt, libgnome,
Santiago Vila <[EMAIL PROTECTED]> writes:
> Sorry for the aol mode, but I fully agree.
>
> If the lack of /opt is not a bug, and no package in the system
> requires it, then I don't see the point in creating it.
I think we should create /opt because the FHS requires it, and
possibly /opt/README.
On 22 Sep 1999, Chris Waters wrote:
> No, it implies that creating these unnecessary, redundant, and
> arguably just-plain-*wrong* directories is *more* support than the
> whole /opt tree needs or deserves. :-p ;-)
>
> Basically, while it may be a form of support, I think it's crossing
> the li
Andreas Voegele <[EMAIL PROTECTED]> writes:
> >> In my opinion, the installation guide should suggest creating
> >> an /opt partition if the user intends to install commercial
> >> software like Applixware, Civilization or the Oracle RDBMS, but
> >> nothing else should be done.
>
Raul Miller <[EMAIL PROTECTED]> writes:
> On Wed, Sep 22, 1999 at 04:18:07PM -0700, Chris Waters wrote:
> > Oh c'mon. You're talking about people who are smart enough to create
> > symlinks in /opt/bin, but aren't smart enough to create the dir in the
> > first place? I don't buy it. :-)
>
> T
On Thu, Sep 23, 1999 at 06:15:49PM +1000, Anand Kumria wrote:
> > > > > That is, that the only consideration about whether a package should be
> > > > > added to main, contrib or non-free be its licensing terms.
> > > > >
> > > > > Packages that are `too buggy to support' or `fail to meet policy
>
>> In my opinion, the installation guide should suggest creating
>> an /opt partition if the user intends to install commercial
>> software like Applixware, Civilization or the Oracle RDBMS, but
>> nothing else should be done.
> What problem is solved by not providing the skel
On Fri, 17 Sep 1999, Josip Rodin wrote:
> On Fri, Sep 17, 1999 at 11:14:44AM +0200, J.H.M. Dassen Ray" wrote:
> > > > That is, that the only consideration about whether a package should be
> > > > added to main, contrib or non-free be its licensing terms.
> > > >
> > > > Packages that are `too bu
On Wed, Sep 22, 1999 at 10:29:36PM -0700, Chris Waters wrote:
> Yes, I've read chapter 2, and I just reread it. What about it? I see
> nothing there that contradicts what I said above. Both /usr (including
> /usr/local) and /opt are static and sharable, so what's the problem?
Oops, I misremembered
Raul Miller <[EMAIL PROTECTED]> writes:
> On Wed, Sep 22, 1999 at 05:51:09PM -0700, Chris Waters wrote:
> > There was nothing stopping them from creating links in /usr/local/bin
> > either -- why would they get the hint all of a sudden from /opt/bin
> > when they didn't from /usr/local/bin? I thi
On Wed, Sep 22, 1999 at 05:51:09PM -0700, Chris Waters wrote:
> There was nothing stopping them from creating links in /usr/local/bin
> either -- why would they get the hint all of a sudden from /opt/bin
> when they didn't from /usr/local/bin? I think that /opt/bin is a bad
> idea in the first pla
Raul Miller <[EMAIL PROTECTED]> writes:
> The issue isn't that they don't know how to create directories -- the
> issue is that without the directories there as a hint, there's a
> decent chance that it's not going to even occur to them to do. For
> example, there are some debian developers who h
On Wed, Sep 22, 1999 at 04:18:07PM -0700, Chris Waters wrote:
> Oh c'mon. You're talking about people who are smart enough to create
> symlinks in /opt/bin, but aren't smart enough to create the dir in the
> first place? I don't buy it. :-)
The issue isn't that they don't know how to create dir
19 matches
Mail list logo
