1 |
On Thu, Apr 7, 2016 at 11:46 AM, William Hubbs <williamh@g.o> wrote: |
2 |
>> #!/bin/bash will work whether you've done a usr merge or not |
3 |
>> #!/usr/bin/bash will probably only work if you've done the usr merge |
4 |
>> #!/usr/bin/python will work whether you've done a usr merge or not |
5 |
>> #!/bin/python will probably only work if you've done the usr merge |
6 |
> |
7 |
> That's correct, but you shouldn't be using shebangs like the second and |
8 |
> fourth ones now either. The standard shebangs (the first and third |
9 |
> ones) are fully compatible pre and post usr merge. |
10 |
> |
11 |
> If people decide to start using non-standard shebangs like your second |
12 |
> and fourth ones above, that is wrong and should be stopped. |
13 |
> |
14 |
|
15 |
Of course, but how will this be easily prevented? If a package |
16 |
(whether new or a routine update) changes a path somewhere it would |
17 |
work just fine in testing, due to the compatibility symlinks. I can't |
18 |
really think of any straightforward way to detect this in an automated |
19 |
fashion either, at least not 100% reliably. |
20 |
|
21 |
Upstream could introduce these paths without a developer noticing, or |
22 |
a developer might just not notice that netstat and bzip2 and more is |
23 |
in /bin, but lsof and xz and less are in /usr/bin. Since we do not |
24 |
have any policy as to what has to go in either path any of these are |
25 |
subject to change at any time as well. Heck, we struggle just to get |
26 |
people to stop using /etc/init.d/functions.sh. |
27 |
|
28 |
Again, I don't see this as a reason not to make it optional, but I |
29 |
suspect that we will find bugs here from time to time which users who |
30 |
run with the split /usr will have to report/fix. |
31 |
|
32 |
-- |
33 |
Rich |