Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Tollef Fog Heen 
]] Aurelien Jarno 

> How can we progress on this bug? We now have bugs #720777, #720778 and
> #720780 which ask for /usr/lib to be created if /lib exists.
> It's something that can be implemented, but before doing so, I would
> like to know if a decision has been taken wrt the policy.

I think the whole lib thing should be avoided and we should nack
it for any new ports.  Ideally, we should also try to get ourselves out
of the hole we've dug ourselves into.

I don't see anybody being against relaxing the requirement for
/usr/local/lib to exist, so we're presumably blocked on more
seconds.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx90927p@xoog.err.no

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Aurelien Jarno 
On Thu, May 08, 2014 at 09:08:58AM +0200, Tollef Fog Heen wrote:
> ]] Aurelien Jarno 
> 
> > How can we progress on this bug? We now have bugs #720777, #720778 and
> > #720780 which ask for /usr/lib to be created if /lib exists.
> > It's something that can be implemented, but before doing so, I would
> > like to know if a decision has been taken wrt the policy.
> 
> I think the whole lib thing should be avoided and we should nack
> it for any new ports.  Ideally, we should also try to get ourselves out
> of the hole we've dug ourselves into.

Unfortunately given we still want to keep multilib compilers in the
archive, we need to provide foreign binaries, and thus install them in
lib. The policy clearly states that a foreign binary should not
be installed in the multiarch path, and that's really a good thing given
how much pain multilib packages are already (especially when people start
to install libc6-dev-amd64:i386 on an amd64 system or things like that).

Currently for being able to build i386 binaries on an amd64 system, you
need to install libc6-i386:amd64, usually used in addition to
libc6:i386. This is a pain from the glibc side as we have to handle the
fact that they both provide ld.so and that they can be removed in any
order. The development of multiarch seems to be more or less stalled
now, people being satisfied of being able to install packages from 
foreign architectures. To be able to progress further we need to solve
the toolchain issue. They are multiple solutions from using foreign
packages to build multilib toolchain, to stopping providing a multilib
toolchain and using either cross compiler or allow both gcc:amd64 and
gcc:i386 to be co-installable.

In any case to support kernel and bootloader packages we need to create
new architectures with a minimal set of packages (basically the
toolchain).

On the other hand if we just continue to wait, 32-bit architectures are
going to die, and the kernel and bootloader issue will simply disappear
;-).


> I don't see anybody being against relaxing the requirement for
> /usr/local/lib to exist, so we're presumably blocked on more
> seconds.

Ok, great.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508114233.gl25...@hall.aurel32.net

Bug#747320: Mandate "type" in /bin/sh

2014-05-08 Thread Bill Allombert 
On Wed, May 07, 2014 at 02:32:39PM +0100, Ian Jackson wrote:
> Package: debian-policy
> Version: 3.9.5.0
> 
> I came across this in /etc/init.d/exim4:
> 
>   OLDIFS="$IFS"
>   IFS=:
>   for p in $PATH; do
> if [ -x "$p/$UPEX4CONF" ]; then
>   IFS="$OLDIFS"
>   $p/$UPEX4CONF $UPEX4OPTS
>   return 0
> fi
>   done
>   IFS="$OLDIFS"
> 
> I imagine that this kind of thing is found in many other places.
> 
> It seems to me that given that dash and bash both provide `type', and
> the underlying functionality necessarily exists in the shell, it would
> be better to mandate that the shell expose it.
> 
> I therefore propose that the following should be added to the list of
> additional features listed in policy 10.4:
> 
>   * The XSI extension `type' must be supported .  It must exit
> zero iff the command is found.  The output format is not
> specified and scripts must not rely on it; scripts should
> rely only on the exit code using a construct such as
>if type foo >/dev/null 2>&1; then ...

Could you do a survey of current valid /bin/sh shells and see which of them
suport XSI type already ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508115339.GB6365@yellowpig

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Bill Allombert 
On Thu, May 08, 2014 at 09:08:58AM +0200, Tollef Fog Heen wrote:
> ]] Aurelien Jarno 
> 
> > How can we progress on this bug? We now have bugs #720777, #720778 and
> > #720780 which ask for /usr/lib to be created if /lib exists.
> > It's something that can be implemented, but before doing so, I would
> > like to know if a decision has been taken wrt the policy.
> 
> I think the whole lib thing should be avoided and we should nack
> it for any new ports.  Ideally, we should also try to get ourselves out
> of the hole we've dug ourselves into.
> 
> I don't see anybody being against relaxing the requirement for
> /usr/local/lib to exist, so we're presumably blocked on more
> seconds.

Indeed, for policy to move forward we need input from knowledgeable developers.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508120015.GC6365@yellowpig

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Tollef Fog Heen 
]] Aurelien Jarno 

> On Thu, May 08, 2014 at 09:08:58AM +0200, Tollef Fog Heen wrote:
> > ]] Aurelien Jarno 
> > 
> > > How can we progress on this bug? We now have bugs #720777, #720778 and
> > > #720780 which ask for /usr/lib to be created if /lib exists.
> > > It's something that can be implemented, but before doing so, I would
> > > like to know if a decision has been taken wrt the policy.
> > 
> > I think the whole lib thing should be avoided and we should nack
> > it for any new ports.  Ideally, we should also try to get ourselves out
> > of the hole we've dug ourselves into.
> 
> Unfortunately given we still want to keep multilib compilers in the
> archive, we need to provide foreign binaries, and thus install them in
> lib. The policy clearly states that a foreign binary should not
> be installed in the multiarch path, and that's really a good thing given
> how much pain multilib packages are already (especially when people start
> to install libc6-dev-amd64:i386 on an amd64 system or things like that).

That is pretty orthogonal to whether we should require
/usr/local/lib to exist, which this bug is about, though. :-)

> > I don't see anybody being against relaxing the requirement for
> > /usr/local/lib to exist, so we're presumably blocked on more
> > seconds.
> 
> Ok, great.

A second would be great if you think we should relax the requirement.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjis5s6u@xoog.err.no

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Jonathan Nieder 
Hi,

Tollef Fog Heen wrote:

> Suggested change:
>
> --- /proc/self/fd/13  2011-02-13 09:12:50.142239544 +0100
> +++ policy.sgml   2011-02-13 09:12:01.565231567 +0100
> @@ -5993,6 +5993,13 @@
>to get access to kernel information.
>  
>
> +  
> +
> +  The requirement for /usr/local/lib
> +  to exist if /lib or 
> +  /usr/lib exists is removed.
> +
> +  
>  

Seconded.  That makes two seconds by my count (me and ballombe).
Remember that any DD including the one who proposed a change can
second a proposal if they think it reflects consensus (or can solicit
more input if they think it needs it).

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508171958.gz9...@google.com

Processed: Re: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was jrnie...@gmail.com).
> usertag 613143 =
Usertags were: normative discussion.
Usertags are now: .
> tags 613143 = patch
Bug #613143 [debian-policy] there is /usr/lib64 symlink but no /usr/local/lib64
Added tag(s) patch.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
613143: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613143
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.139956976927134.transcr...@bugs.debian.org

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Russ Allbery 
Jonathan Nieder  writes:
> Tollef Fog Heen wrote:

>> Suggested change:
>>
>> --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100
>> +++ policy.sgml  2011-02-13 09:12:01.565231567 +0100
>> @@ -5993,6 +5993,13 @@
>>to get access to kernel information.
>>  
>>
>> +  
>> +
>> +  The requirement for 
>> /usr/local/lib
>> +  to exist if /lib or 
>> +  /usr/lib exists is removed.
>> +
>> +  
>>  

> Seconded.  That makes two seconds by my count (me and ballombe).
> Remember that any DD including the one who proposed a change can
> second a proposal if they think it reflects consensus (or can solicit
> more input if they think it needs it).

I second this as well, although I think it's unnecessary at this point.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tw45f1p@windlord.stanford.edu

Processed: Re: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> tags 613143 = pending
Bug #613143 [debian-policy] there is /usr/lib64 symlink but no /usr/local/lib64
Added tag(s) pending; removed tag(s) patch.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
613143: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613143
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.139957296614452.transcr...@bugs.debian.org

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Jonathan Nieder 
tags 613143 = pending
quit

Russ Allbery wrote:

> I second this as well, although I think it's unnecessary at this point.

Thanks.  Applied.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508181557.gc9...@google.com

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Bill Allombert 
On Thu, May 08, 2014 at 11:15:57AM -0700, Jonathan Nieder wrote:
> tags 613143 = pending
> quit
> 
> Russ Allbery wrote:
> 
> > I second this as well, although I think it's unnecessary at this point.
> 
> Thanks.  Applied.

Well, I was working on a patch that looks like:

+  The requirement for /usr/local/lib
+  to exist if /lib or
+  /usr/lib exists (where
+   is either 32 or 64) is removed.

i.e. try to explain what  is.

(Also I do not remember having seconded the patch, but it do not matter.)

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508192551.GA9882@yellowpig

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Jonathan Nieder 
Bill Allombert wrote:
> On Thu, May 08, 2014 at 11:15:57AM -0700, Jonathan Nieder wrote:

>> Thanks.  Applied.
>
> Well, I was working on a patch that looks like:
>
> +  The requirement for /usr/local/lib
> +  to exist if /lib or
> +  /usr/lib exists (where
> +   is either 32 or 64) is removed.
>
> i.e. try to explain what  is.

FWIW I don't mind if you tweak the wording.

Unfortunately it's not just  = 32 or 64[1].  Luckily the only
ones that would be relevant the way Debian uses  are

  = 32 (mips, tilegx)
  = 64 (mips, powerpc, x86)
  = x32 (x86)

from https://sourceware.org/glibc/wiki/ABIList.

> (Also I do not remember having seconded the patch, but it do not matter.)

http://bugs.debian.org/613143#22

Thanks,
Jonathan

[1] The FHS just says "There may be one or more variants".
https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508195105.gd9...@google.com

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Bill Allombert 
On Thu, May 08, 2014 at 12:51:05PM -0700, Jonathan Nieder wrote:
> Bill Allombert wrote:
> > On Thu, May 08, 2014 at 11:15:57AM -0700, Jonathan Nieder wrote:
> 
> >> Thanks.  Applied.
> >
> > Well, I was working on a patch that looks like:
> >
> > +  The requirement for 
> > /usr/local/lib
> > +  to exist if /lib or
> > +  /usr/lib exists (where
> > +   is either 32 or 64) is removed.
> >
> > i.e. try to explain what  is.
> 
> FWIW I don't mind if you tweak the wording.
> 
> Unfortunately it's not just  = 32 or 64[1].  Luckily the only
> ones that would be relevant the way Debian uses  are
> 
>   = 32 (mips, tilegx)
>   = 64 (mips, powerpc, x86)
>   = x32 (x86)
> 

However the FHS version mandated by policy does not include libx32,
so it could be argued that there is no need for a FHS exception for
libx32.

> from https://sourceware.org/glibc/wiki/ABIList.

Thanks for the link.

> > (Also I do not remember having seconded the patch, but it do not matter.)
> 
> http://bugs.debian.org/613143#22

Indeed!

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508201313.GB9882@yellowpig

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Jonathan Nieder 
Bill Allombert wrote:
> On Thu, May 08, 2014 at 12:51:05PM -0700, Jonathan Nieder wrote:

>> FWIW I don't mind if you tweak the wording.
>>
>> Unfortunately it's not just  = 32 or 64[1].  Luckily the only
>> ones that would be relevant the way Debian uses  are
>>
>>   = 32 (mips, tilegx)
>>   = 64 (mips, powerpc, x86)
>>   = x32 (x86)
>
> However the FHS version mandated by policy does not include libx32,
> so it could be argued that there is no need for a FHS exception for
> libx32.

If I understand correctly then alas, no --- the FHS meaning of 
is open ended.

When it describes lib32 and lib64 it says

The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must
place 64-bit libraries in /lib64, and 32-bit (or 31-bit on
s390) libraries in /lib.

The 64-bit architecture IA64 must place 64-bit libraries in /lib.

This is a refinement of the general rules for /lib and
/usr/lib.

In other words, there are rules elsewhere in the document about how
lib works generally for lib32, lib64, libx32, libxyzzy, or
whatever, and here are the more specific rules that govern lib, lib32,
and lib64 on PPC64, s390x, sparc64, AMD64, and IA64.

How about the following (text as before, except a parenthesized phrase
added)?

The requirement for /usr/local/lib to exist if /lib or
/usr/lib exists (where lib is a variant of lib such as
lib32 or lib64) is removed.

"such as" should cover any future lib directories.

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508202042.ge9...@google.com

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Tollef Fog Heen 
]] Jonathan Nieder 

> Seconded.  That makes two seconds by my count (me and ballombe).
> Remember that any DD including the one who proposed a change can
> second a proposal if they think it reflects consensus (or can solicit
> more input if they think it needs it).

I didn't realise you can second your own proposal, but I'm happy to
second my proposal in that case, so seconded too.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m238gkkm9l@rahvafeir.err.no

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

2014-05-08 Thread Russ Allbery 
Tollef Fog Heen  writes:
> ]] Jonathan Nieder 

>> Seconded.  That makes two seconds by my count (me and ballombe).
>> Remember that any DD including the one who proposed a change can
>> second a proposal if they think it reflects consensus (or can solicit
>> more input if they think it needs it).

> I didn't realise you can second your own proposal, but I'm happy to
> second my proposal in that case, so seconded too.

Yeah, we require three seconds, but the proposer can second.  I usually
count the proposal as an implicit second if it's from a DD.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k39v20an@windlord.stanford.edu