On Tue, May 31, 2011 at 05:55:16PM -0700, Toshio Kuratomi wrote:
On Wed, Jun 01, 2011 at 12:23:42AM +0200, Petr Sabata wrote:
On Tue, May 31, 2011 at 10:16:02AM -0700, Toshio Kuratomi wrote:
On Mon, May 30, 2011 at 11:24:08AM +0200, Petr Sabata wrote:
On Thu, May 26, 2011 at 10:19:43AM
On Mon, May 30, 2011 at 11:24:08AM +0200, Petr Sabata wrote:
On Thu, May 26, 2011 at 10:19:43AM -0400, Matthew Miller wrote:
On Thu, May 26, 2011 at 02:23:44PM +0200, Jakub Jelinek wrote:
As I understand it, the best way to do this in Fedora, with respect to
same ideas in this thread,
On Tue, May 31, 2011 at 10:16:02AM -0700, Toshio Kuratomi wrote:
On Mon, May 30, 2011 at 11:24:08AM +0200, Petr Sabata wrote:
On Thu, May 26, 2011 at 10:19:43AM -0400, Matthew Miller wrote:
On Thu, May 26, 2011 at 02:23:44PM +0200, Jakub Jelinek wrote:
As I understand it, the best way
On Thu, May 26, 2011 at 10:19:43AM -0400, Matthew Miller wrote:
On Thu, May 26, 2011 at 02:23:44PM +0200, Jakub Jelinek wrote:
As I understand it, the best way to do this in Fedora, with respect to
same ideas in this thread, would be having %{_libexecdir}/plan9 or
similar,
with bin,
Le Lun 30 mai 2011 11:24, Petr Sabata a écrit :
That would indeed be better, I guess.
It's okay with both FHS 2.3 and our current Guidelines (or maybe I'm just
missing something), rpmlint complains about %{_bindir} subdirectory, though.
Again /usr/bin/ subdirectories are not used in Fedora
On Mon, May 30, 2011 at 03:33, Nicolas Mailhot
nicolas.mail...@laposte.net wrote:
Le Lun 30 mai 2011 11:24, Petr Sabata a écrit :
That would indeed be better, I guess.
It's okay with both FHS 2.3 and our current Guidelines (or maybe I'm just
missing something), rpmlint complains about
Le Mer 25 mai 2011 20:39, seth vidal a écrit :
I think that's completely appropriate.
But does that mean the pkg should stay out of the distro?
Note that there is *no* problem if the binaries are renamed in /usr/bin with
an explicit prefix, as has been asked from the beginning.
--
Nicolas
On Fri, May 20, 2011 at 02:17:17PM +0200, Petr Sabata wrote:
Hi list,
I've been thinking about packaging 9base [1], a port of Plan 9 userspace
tools,
for Fedora. I'm interested in opinions on what style is better and why.
The problem is most of 9base binaries (and their manpages) have
On Thu, May 26, 2011 at 02:18:07PM +0200, Petr Sabata wrote:
I'd like to thank all for their input.
As I understand it, the best way to do this in Fedora, with respect to
same ideas in this thread, would be having %{_libexecdir}/plan9 or similar,
with bin, lib and share (or whatever upstream
On Thu, May 26, 2011 at 02:23:44PM +0200, Jakub Jelinek wrote:
On Thu, May 26, 2011 at 02:18:07PM +0200, Petr Sabata wrote:
I'd like to thank all for their input.
As I understand it, the best way to do this in Fedora, with respect to
same ideas in this thread, would be having
On Thu, May 26, 2011 at 02:23:44PM +0200, Jakub Jelinek wrote:
As I understand it, the best way to do this in Fedora, with respect to
same ideas in this thread, would be having %{_libexecdir}/plan9 or similar,
with bin, lib and share (or whatever upstream supplies) subdirectories.
You
Petr Sabata (con...@redhat.com) said:
Simply to make Fedora better. I'd like to make those available for our
users.
There are currently no other packages relying on this set (or rc, to be
more
specific) in Fedora. That could change in the future, though.
The question is -
On Tue, May 24, 2011 at 10:59:27AM -0600, Stephen John Smoogen wrote:
On Tue, May 24, 2011 at 10:35, Matthew Miller mat...@mattdm.org wrote:
On Tue, May 24, 2011 at 09:28:02AM +0200, Nicolas Mailhot wrote:
There is no reason not to put them in /usr/lib(64). That's where common
binaries such
Nicolas Mailhot wrote:
There is no reason not to put them in /usr/lib(64). That's where common
binaries such as firefox, java, etc already reside. They all have magic
env variables to define their root for scripts and
symlinks/wrappers/alternatives in /usr/bin
Well, actually, the proper place
Petr Sabata (con...@redhat.com) said:
There is no reason not to put them in /usr/lib(64). That's where common
binaries such as firefox, java, etc already reside. They all have magic
env variables to define their root for scripts and
symlinks/wrappers/alternatives in /usr/bin
On Wed, May 25, 2011 at 11:36:10AM -0400, Bill Nottingham wrote:
Petr Sabata (con...@redhat.com) said:
There is no reason not to put them in /usr/lib(64). That's where common
binaries such as firefox, java, etc already reside. They all have magic
env variables to define their root
On Wed, May 25, 2011 at 05:59:36PM +0200, Petr Sabata wrote:
On Wed, May 25, 2011 at 11:36:10AM -0400, Bill Nottingham wrote:
The question is - why does having incompatible plan9 implementations of
common commands make Fedora 'better', outside of having more stuff?
You could say the
On Wed, 2011-05-25 at 17:52 +0100, Matthew Garrett wrote:
On Wed, May 25, 2011 at 05:59:36PM +0200, Petr Sabata wrote:
On Wed, May 25, 2011 at 11:36:10AM -0400, Bill Nottingham wrote:
The question is - why does having incompatible plan9 implementations of
common commands make Fedora
On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
What would cause someone to choose to use these tools rather than the
ones that exist in Fedora already?
They come from an environment where plan9 is more commonly used
Rob Pike's house ?
Dave
--
devel mailing
On Wed, 2011-05-25 at 13:10 -0400, Dave Jones wrote:
On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
What would cause someone to choose to use these tools rather than the
ones that exist in Fedora already?
They come from an environment where plan9 is more commonly
On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
On Wed, 2011-05-25 at 17:52 +0100, Matthew Garrett wrote:
What would cause someone to choose to use these tools rather than the
ones that exist in Fedora already?
They come from an environment where plan9 is more commonly used
Hi.
On Wed, 25 May 2011 13:18:20 -0400, seth vidal wrote
I keep forgetting who fedora is for.
It's not like the problem of having multiple implementations of
basic UNIX command line tools has never come up before, though.
Solaris has been doing that for quite a long time.
On Wed, May 25, 2011 at 01:42:02PM -0400, seth vidal wrote:
On Wed, 2011-05-25 at 18:41 +0100, Matthew Garrett wrote:
On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
On Wed, 2011-05-25 at 17:52 +0100, Matthew Garrett wrote:
What would cause someone to choose to use these
On Wed, 2011-05-25 at 19:14 +0100, Matthew Garrett wrote:
On Wed, May 25, 2011 at 01:42:02PM -0400, seth vidal wrote:
On Wed, 2011-05-25 at 18:41 +0100, Matthew Garrett wrote:
On Wed, May 25, 2011 at 12:56:25PM -0400, seth vidal wrote:
On Wed, 2011-05-25 at 17:52 +0100, Matthew Garrett
On Wed, May 25, 2011 at 02:21:04PM -0400, seth vidal wrote:
On Wed, 2011-05-25 at 19:14 +0100, Matthew Garrett wrote:
If they're used to plan9, they'll presumably want these in their path.
If they're in their path, other utilities are going to misbehave in ways
that will be difficult to
On Wed, May 25, 2011 at 1:41 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
Putting them in your path's just going to break things.
The plan is to have them _prefixed_ in your path, and un-prefixed in a
specified directory so you can frob the path to run scripts that
expect p9 utilities.
I am
On Wed, 2011-05-25 at 19:35 +0100, Matthew Garrett wrote:
On Wed, May 25, 2011 at 02:21:04PM -0400, seth vidal wrote:
On Wed, 2011-05-25 at 19:14 +0100, Matthew Garrett wrote:
If they're used to plan9, they'll presumably want these in their path.
If they're in their path, other utilities
On Wed, May 25, 2011 at 02:39:16PM -0400, seth vidal wrote:
On Wed, 2011-05-25 at 19:35 +0100, Matthew Garrett wrote:
If I get a bug complaining that something doesn't work because the user
is using plan9 awk rather than gnu awk, they're going to get very firmly
NOTABUGged. I hardly think
On Wed, May 25, 2011 at 02:35:09PM -0400, Martin Langhoff wrote:
On Wed, May 25, 2011 at 1:41 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
Putting them in your path's just going to break things.
The plan is to have them _prefixed_ in your path, and un-prefixed in a
specified directory so
On Wed, 2011-05-25 at 19:53 +0100, Matthew Garrett wrote:
On Wed, May 25, 2011 at 02:39:16PM -0400, seth vidal wrote:
On Wed, 2011-05-25 at 19:35 +0100, Matthew Garrett wrote:
If I get a bug complaining that something doesn't work because the user
is using plan9 awk rather than gnu awk,
On Wed, May 25, 2011 at 01:03, Petr Sabata con...@redhat.com wrote:
On Tue, May 24, 2011 at 10:59:27AM -0600, Stephen John Smoogen wrote:
On Tue, May 24, 2011 at 10:35, Matthew Miller mat...@mattdm.org wrote:
On Tue, May 24, 2011 at 09:28:02AM +0200, Nicolas Mailhot wrote:
There is no reason
On Wed, May 25, 2011 at 09:36, Bill Nottingham nott...@redhat.com wrote:
Petr Sabata (con...@redhat.com) said:
There is no reason not to put them in /usr/lib(64). That's where common
binaries such as firefox, java, etc already reside. They all have magic
env variables to define their
ons 2011-05-25 klockan 19:14 +0100 skrev Matthew Garrett:
If they're in their path, other utilities are going to misbehave in
ways
that will be difficult to debug.
The user could add the directory to PATH without exporting PATH to
subprocesses, or they could use the shell's alias
Le Lun 23 mai 2011 17:55, Matthew Miller a écrit :
On Mon, May 23, 2011 at 09:54:48AM +0200, Nicolas Mailhot wrote:
1. install libraries (and binaries? see 3.) in /usr/lib(64)
Large software packages must not use a direct subdirectory under
the /usr hierarchy.
2. provide prefixed
On 20/05/11 14:17, Petr Sabata wrote:
Hi list,
I've been thinking about packaging 9base [1], a port of Plan 9 userspace
tools,
for Fedora. I'm interested in opinions on what style is better and why.
The problem is most of 9base binaries (and their manpages) have the same
name as their
On Tue, May 24, 2011 at 09:28:02AM +0200, Nicolas Mailhot wrote:
There is no reason not to put them in /usr/lib(64). That's where common
binaries such as firefox, java, etc already reside. They all have magic
env variables to define their root for scripts and
symlinks/wrappers/alternatives in
On Tue, May 24, 2011 at 10:35, Matthew Miller mat...@mattdm.org wrote:
On Tue, May 24, 2011 at 09:28:02AM +0200, Nicolas Mailhot wrote:
There is no reason not to put them in /usr/lib(64). That's where common
binaries such as firefox, java, etc already reside. They all have magic
env variables
On Mon, May 23, 2011 at 09:36:52AM +0200, Petr Sabata wrote:
On Sat, May 21, 2011 at 10:08:01AM +0200, Alexander Boström wrote:
fre 2011-05-20 klockan 14:17 +0200 skrev Petr Sabata:
#1, aka the Gentoo way
Gentoo installs its 9base package into /usr/plan9, basically not
The correct way to do this in Fedora and in the FHS is to :
1. install libraries (and binaries? see 3.) in /usr/lib(64)
Large software packages must not use a direct subdirectory under
the /usr hierarchy.
2. provide prefixed :
— binaries or
— symlinks to binaries in
On Fri, May 20, 2011 at 12:21:09PM -0400, Adam Jackson wrote:
Yeah, #1 sounds less awful.
The other option is /opt/plan9, which might be more in the spirit of
what the FHS says, but the packaging guidelines currently don't mention
/opt at all.
Please keep RPMs out of /opt. It's what
On Mon, May 23, 2011 at 09:54:48AM +0200, Nicolas Mailhot wrote:
1. install libraries (and binaries? see 3.) in /usr/lib(64)
Large software packages must not use a direct subdirectory under
the /usr hierarchy.
2. provide prefixed :
— binaries or
— symlinks to binaries in
Matthew Miller wrote:
Since we also already ship the environment-modules package, an env-module
for plan 9 could be included; users who want the plan 9 binaries could
either set their path manually or run module load plan9.
This seems preferable to the alternatives system, since it's
On Mon, May 23, 2011 at 09:27:39PM +0200, Kevin Kofler wrote:
This seems preferable to the alternatives system, since it's per-user
rather than systemwide.
Alternatives is entirely unacceptable for this kind of core system binaries
anyway. You break a lot of things if e.g. /bin/ls suddenly
fre 2011-05-20 klockan 14:17 +0200 skrev Petr Sabata:
#1, aka the Gentoo way
Gentoo installs its 9base package into /usr/plan9, basically not touching
9base files at all. This collides with FHS and therefore would require an
exception in Packaging Guidelines.
About /usr, FHS
Hi list,
I've been thinking about packaging 9base [1], a port of Plan 9 userspace tools,
for Fedora. I'm interested in opinions on what style is better and why.
The problem is most of 9base binaries (and their manpages) have the same
name as their coreutils (and other) equivalents, therefore we
On 5/20/11 8:17 AM, Petr Sabata wrote:
#1, aka the Gentoo way
Gentoo installs its 9base package into /usr/plan9, basically not touching
9base files at all. This collides with FHS and therefore would require an
exception in Packaging Guidelines.
#2, aka the Debian
46 matches
Mail list logo
