public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
* [RFC] libexecdir
@ 2013-06-19 19:33 Yaakov (Cygwin/X)
  2013-06-20  8:20 ` Corinna Vinschen
  0 siblings, 1 reply; 7+ messages in thread
From: Yaakov (Cygwin/X) @ 2013-06-19 19:33 UTC (permalink / raw)
  To: cygwin-apps

The Linux Foundation has taken over development of the FHS[1], and have 
added /usr/libexec[2] to the forthcoming 3.0 spec, based in its 
widespread use in some Linux distributions and other *NIX systems (*BSD, 
Minix, perhaps others).

Should we do the same on Cygwin by changing the default cygconf() flags 
in cygport?  It will mean some changes to [PKG]_CONTENTS will be 
necessary for packages relying on the current --libexecdir=/usr/lib 
default (gcc and git come to mind).


Yaakov

[1] http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs
[2] http://bzr.linuxfoundation.org/loggerhead/lsb/devel/fhs-spec/revision/44

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] libexecdir
  2013-06-19 19:33 [RFC] libexecdir Yaakov (Cygwin/X)
@ 2013-06-20  8:20 ` Corinna Vinschen
  2013-06-20 14:19   ` Christopher Faylor
  0 siblings, 1 reply; 7+ messages in thread
From: Corinna Vinschen @ 2013-06-20  8:20 UTC (permalink / raw)
  To: cygwin-apps

On Jun 19 14:33, Yaakov (Cygwin/X) wrote:
> The Linux Foundation has taken over development of the FHS[1], and
> have added /usr/libexec[2] to the forthcoming 3.0 spec, based in its
> widespread use in some Linux distributions and other *NIX systems
> (*BSD, Minix, perhaps others).
> 
> Should we do the same on Cygwin by changing the default cygconf()
> flags in cygport?  It will mean some changes to [PKG]_CONTENTS will
> be necessary for packages relying on the current
> --libexecdir=/usr/lib default (gcc and git come to mind).

I'm not all too keen to get the /usr/libexec dir, but I noticed that
it's used already anyway.

I have no strong opinion against this change, and I do hope that this
only results in a few cygport file changes, but I think this will also
result in some problems.

Let's say, for instance, the inetutils package changes the installation
path of its daemons.  This affects the inetd.conf file, which could
also be changed by the user to start other stuff.

Or, take the openssh package, which has sshd as well as its tools
installed into /usr/sbin right now.  If we move them, we may end up
breaking user scripts.

Conflicts like this will happen.  If we change libexec, we have to be
prepared for this kind of stuff.  Is it worth it?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] libexecdir
  2013-06-20  8:20 ` Corinna Vinschen
@ 2013-06-20 14:19   ` Christopher Faylor
  2013-06-20 15:11     ` Corinna Vinschen
  0 siblings, 1 reply; 7+ messages in thread
From: Christopher Faylor @ 2013-06-20 14:19 UTC (permalink / raw)
  To: cygwin-apps

On Thu, Jun 20, 2013 at 10:20:51AM +0200, Corinna Vinschen wrote:
>Conflicts like this will happen.  If we change libexec, we have to be
>prepared for this kind of stuff.  Is it worth it?

I certainly have gone through this "pain" when the changeover was made
on Linux.  If we want to provide the real Linux look-and-feel I don't
think we have any choice.  :-)

But, seriously, I think that the change makes sense in the long run. If
we don't do this we'll eventually just have to be tweaking more and more
configurations to put things in /usr/libexec rather than /usr/lib.

On a similar note, what about Fedora (and others) fusion of /usr/bin <> /bin
and /usr/sbin <> /sbin?  Do we want to think about that too?  It would
certainly make sense for Cygwin.  We could get rid of /usr/bin entirely.

cgf

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] libexecdir
  2013-06-20 14:19   ` Christopher Faylor
@ 2013-06-20 15:11     ` Corinna Vinschen
  2013-06-20 15:15       ` Corinna Vinschen
  2013-06-20 15:17       ` Christopher Faylor
  0 siblings, 2 replies; 7+ messages in thread
From: Corinna Vinschen @ 2013-06-20 15:11 UTC (permalink / raw)
  To: cygwin-apps

On Jun 20 10:19, Christopher Faylor wrote:
> On Thu, Jun 20, 2013 at 10:20:51AM +0200, Corinna Vinschen wrote:
> >Conflicts like this will happen.  If we change libexec, we have to be
> >prepared for this kind of stuff.  Is it worth it?
> 
> I certainly have gone through this "pain" when the changeover was made
> on Linux.  If we want to provide the real Linux look-and-feel I don't
> think we have any choice.  :-)
> 
> But, seriously, I think that the change makes sense in the long run. If
> we don't do this we'll eventually just have to be tweaking more and more
> configurations to put things in /usr/libexec rather than /usr/lib.

Yeah, probably.  Me and my lawn...

> On a similar note, what about Fedora (and others) fusion of /usr/bin <> /bin
> and /usr/sbin <> /sbin?  Do we want to think about that too?  It would
> certainly make sense for Cygwin.  We could get rid of /usr/bin entirely.

No, we can't.  Fedora has /usr/bin, /usr/lib and /usr/sbin, while the
/bin, /lib, and /sbin paths are just symlinks to their /usr counterparts.
This is necessary to maintain hardcode paths, and this will not go away
in Fedora for a long time.

For Cygwin we did this fusion anyway since version 1.1 or so, just as
mount points and in the other direction.  We were far ahead of time :)

Having said that, we could do the same for /sbin vs. /usr/sbin and
create an automatic mount point for it as well.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] libexecdir
  2013-06-20 15:11     ` Corinna Vinschen
@ 2013-06-20 15:15       ` Corinna Vinschen
  2013-06-20 15:17       ` Christopher Faylor
  1 sibling, 0 replies; 7+ messages in thread
From: Corinna Vinschen @ 2013-06-20 15:15 UTC (permalink / raw)
  To: cygwin-apps

On Jun 20 17:10, Corinna Vinschen wrote:
> On Jun 20 10:19, Christopher Faylor wrote:
> > On Thu, Jun 20, 2013 at 10:20:51AM +0200, Corinna Vinschen wrote:
> > >Conflicts like this will happen.  If we change libexec, we have to be
> > >prepared for this kind of stuff.  Is it worth it?
> > 
> > I certainly have gone through this "pain" when the changeover was made
> > on Linux.  If we want to provide the real Linux look-and-feel I don't
> > think we have any choice.  :-)
> > 
> > But, seriously, I think that the change makes sense in the long run. If
> > we don't do this we'll eventually just have to be tweaking more and more
> > configurations to put things in /usr/libexec rather than /usr/lib.
> 
> Yeah, probably.  Me and my lawn...
> 
> > On a similar note, what about Fedora (and others) fusion of /usr/bin <> /bin
> > and /usr/sbin <> /sbin?  Do we want to think about that too?  It would
> > certainly make sense for Cygwin.  We could get rid of /usr/bin entirely.
> 
> No, we can't.  Fedora has /usr/bin, /usr/lib and /usr/sbin, while the
> /bin, /lib, and /sbin paths are just symlinks to their /usr counterparts.
> This is necessary to maintain hardcode paths, and this will not go away
> in Fedora for a long time.
> 
> For Cygwin we did this fusion anyway since version 1.1 or so, just as
> mount points and in the other direction.  We were far ahead of time :)
> 
> Having said that, we could do the same for /sbin vs. /usr/sbin and
> create an automatic mount point for it as well.

OTOH, in an existing installation this requires to move the existing
files in /usr/sbin to /sbin before installing the new Cygwin maintaining
the auto mount point.  Hmm.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] libexecdir
  2013-06-20 15:11     ` Corinna Vinschen
  2013-06-20 15:15       ` Corinna Vinschen
@ 2013-06-20 15:17       ` Christopher Faylor
  2013-06-20 15:31         ` Corinna Vinschen
  1 sibling, 1 reply; 7+ messages in thread
From: Christopher Faylor @ 2013-06-20 15:17 UTC (permalink / raw)
  To: cygwin-apps

On Thu, Jun 20, 2013 at 05:10:57PM +0200, Corinna Vinschen wrote:
>On Jun 20 10:19, Christopher Faylor wrote:
>> On Thu, Jun 20, 2013 at 10:20:51AM +0200, Corinna Vinschen wrote:
>> >Conflicts like this will happen.  If we change libexec, we have to be
>> >prepared for this kind of stuff.  Is it worth it?
>> 
>> I certainly have gone through this "pain" when the changeover was made
>> on Linux.  If we want to provide the real Linux look-and-feel I don't
>> think we have any choice.  :-)
>> 
>> But, seriously, I think that the change makes sense in the long run. If
>> we don't do this we'll eventually just have to be tweaking more and more
>> configurations to put things in /usr/libexec rather than /usr/lib.
>
>Yeah, probably.  Me and my lawn...

I see you got what I meant even though I got the sense wrong.

>> On a similar note, what about Fedora (and others) fusion of /usr/bin <> /bin
>> and /usr/sbin <> /sbin?  Do we want to think about that too?  It would
>> certainly make sense for Cygwin.  We could get rid of /usr/bin entirely.
>
>No, we can't.  Fedora has /usr/bin, /usr/lib and /usr/sbin, while the
>/bin, /lib, and /sbin paths are just symlinks to their /usr counterparts.
>This is necessary to maintain hardcode paths, and this will not go away
>in Fedora for a long time.

I guess I should have checked before sending the email but my point was
if we should be eschewing the use of whichever Fedora has gotten rid of.
You're right that /bin is a symlink.  So should cygport and others now
be forcing everything into /usr/whatever?

>For Cygwin we did this fusion anyway since version 1.1 or so, just as
>mount points and in the other direction.  We were far ahead of time :)
>
>Having said that, we could do the same for /sbin vs. /usr/sbin and
>create an automatic mount point for it as well.

Although I think they were my idea, I have never really liked the
automatic mount points.  Couldn't we just use a symlink?

cgf

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] libexecdir
  2013-06-20 15:17       ` Christopher Faylor
@ 2013-06-20 15:31         ` Corinna Vinschen
  0 siblings, 0 replies; 7+ messages in thread
From: Corinna Vinschen @ 2013-06-20 15:31 UTC (permalink / raw)
  To: cygwin-apps

On Jun 20 11:17, Christopher Faylor wrote:
> On Thu, Jun 20, 2013 at 05:10:57PM +0200, Corinna Vinschen wrote:
> >On Jun 20 10:19, Christopher Faylor wrote:
> >> On Thu, Jun 20, 2013 at 10:20:51AM +0200, Corinna Vinschen wrote:
> >> >Conflicts like this will happen.  If we change libexec, we have to be
> >> >prepared for this kind of stuff.  Is it worth it?
> >> 
> >> I certainly have gone through this "pain" when the changeover was made
> >> on Linux.  If we want to provide the real Linux look-and-feel I don't
> >> think we have any choice.  :-)
> >> 
> >> But, seriously, I think that the change makes sense in the long run. If
> >> we don't do this we'll eventually just have to be tweaking more and more
> >> configurations to put things in /usr/libexec rather than /usr/lib.
> >
> >Yeah, probably.  Me and my lawn...
> 
> I see you got what I meant even though I got the sense wrong.
> 
> >> On a similar note, what about Fedora (and others) fusion of /usr/bin <> /bin
> >> and /usr/sbin <> /sbin?  Do we want to think about that too?  It would
> >> certainly make sense for Cygwin.  We could get rid of /usr/bin entirely.
> >
> >No, we can't.  Fedora has /usr/bin, /usr/lib and /usr/sbin, while the
> >/bin, /lib, and /sbin paths are just symlinks to their /usr counterparts.
> >This is necessary to maintain hardcode paths, and this will not go away
> >in Fedora for a long time.
> 
> I guess I should have checked before sending the email but my point was
> if we should be eschewing the use of whichever Fedora has gotten rid of.
> You're right that /bin is a symlink.  So should cygport and others now
> be forcing everything into /usr/whatever?

By default prefix is /usr anyway when building packages with cygport.  I
don't see a reason to disable packages from specifing /bin as installation
path.  After all, it's dumped into the same place anyway.

> >For Cygwin we did this fusion anyway since version 1.1 or so, just as
> >mount points and in the other direction.  We were far ahead of time :)
> >
> >Having said that, we could do the same for /sbin vs. /usr/sbin and
> >create an automatic mount point for it as well.
> 
> Although I think they were my idea, I have never really liked the
> automatic mount points.  Couldn't we just use a symlink?

I'm not really loving them either, but the original reason to have
/usr/bin and /usr/lib mount points rather than symlinks is performance.
That was already the case in pre-1.7 Cygwin when we had the automatic
generation of the /usr/bin and /usr/lib mount points in the registry.

Handling mount points is noticably faster than handling symlinks.
Symlinks require to read file content and since /usr/bin is first in
$PATH by default, you get lots and lots of open/read/close calls on the
/usr/bin symlink.  Even if the file is cached, it's probably still
slower than just fetching the mount point from the internal mount table.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2013-06-20 15:31 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-19 19:33 [RFC] libexecdir Yaakov (Cygwin/X)
2013-06-20  8:20 ` Corinna Vinschen
2013-06-20 14:19   ` Christopher Faylor
2013-06-20 15:11     ` Corinna Vinschen
2013-06-20 15:15       ` Corinna Vinschen
2013-06-20 15:17       ` Christopher Faylor
2013-06-20 15:31         ` Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).