2015-02-17 18:02 GMT+01:00 Donn Cave donn@xxxxxxxxxxx:
I don't see any major problem with the current
configuration, but it would be a bad move to make the production release
configuration hostile to anyone but this narrow definition of end users.
How is having an additional element in the path hostile? If you are
power user you can figure it out. If you can't then our documentation
is lacking, not the implementation.
- Kacper
...

Quoth Kacper Kasper kacperkasper@xxxxxxxxx,
By non-developers Augustin meant people who do not develop SOFTWARE,
not just Haiku.
If you do that, you're either software developer or power user, and
both in my opinion do not fit the definition of end user we are
talking about here.
I think that's an artificial and unproductive distinction. Early in the
game, power users of one sort or another are not only end users, they're
...

Il 17/feb/2015 16:49 Jonathan Beatty easyegoism@xxxxxxxxx ha scritto:
Absurd argument. I'm not a developer of Linux, although I use it all the
time, and I put scripts and binaries wherever I please quite frequently.
Contempt of community indeed.
Well, if you're really putting scripts and binaries wherever you want in
Linux you're doing it wrong, since you're supposed to use /usr/local/bin or
the other local paths which (oh no!) are longer than the respective
packaged paths, just like on haiku with PM.
...

On 02/17/2015 04:49 PM, Jonathan Beatty wrote:
Absurd argument. I'm not a developer of Linux, although I use it all the
time, and I put scripts and binaries wherever I please quite frequently.
Contempt of community indeed.
First of all: Please don't top-post.
...

2015-02-17 16:49 GMT+01:00 Jonathan Beatty easyegoism@xxxxxxxxx:
Absurd argument. I'm not a developer of Linux, although I use it all the
time, and I put scripts and binaries wherever I please quite frequently.
Absurd as well. By non-developers Augustin meant people who do not
develop SOFTWARE, not just Haiku.
If you do that, you're either software developer or power user, and
both in my opinion do not fit the definition of end user we are
talking about here.
- Kacper
...

Absurd argument. I'm not a developer of Linux, although I use it all the
time, and I put scripts and binaries wherever I please quite frequently.
Contempt of community indeed.
On Tue, Feb 17, 2015, 9:46 AM Augustin Cavalier waddlesplash@xxxxxxxxx
wrote:
On Tue, Feb 17, 2015 at 10:41 AM, Jim Saxton black.belt.jimmy@xxxxxxxxx
wrote:
...

On Tue, Feb 17, 2015 at 10:41 AM, Jim Saxton black.belt.jimmy@xxxxxxxxx
wrote:
Using this tree structure will increased the support time needed by
new users. It will devrease the adoption rate for haiku when it
reaches r1.
On the contrary: the end users (who aren't developers) should not even know
about this.
...

On Tue, Feb 17, 2015 at 10:37 AM, Donn Cave donn@xxxxxxxxxxx wrote:
That seems like asking for trouble - provide a non-packaged alternative
to the package system, but say (to yourselves) it's not really to be used.
So you can pull it later, and say no one should have using it? It seems
unlikely that there will ever be any need to lock the system down to
packaged files only, why not accept this as a virtue of the design?
No. Having non-packaged is very useful to developers, who may want to test
...

On 2/17/15, Augustin Cavalier waddlesplash@xxxxxxxxx wrote:
On 2/16/2015 11:12 PM, Chase Rayfield (Redacted sender
cusbrar2@xxxxxxxxx for DMARC) wrote:
~/config/ and ~/config/non-packaged
over ~/config/packaged and ~/config
Because ~/config/non-packaged was/is supposed to be temporary and only
used by e.g. developers testing software. End-users should get all their
software via HPKGs, or unzip and run anywhere.
...

Quoth Augustin Cavalier waddlesplash@xxxxxxxxx,
Because ~/config/non-packaged was/is supposed to be temporary and only
used by e.g. developers testing software. End-users should get all their
software via HPKGs, or unzip and run anywhere.
That seems like asking for trouble - provide a non-packaged alternative
to the package system, but say (to yourselves) it's not really to be used.
So you can pull it later, and say no one should have using it? It seems
unlikely that there will ever be any need to lock the system down to
...

On 2/16/2015 11:12 PM, Chase Rayfield (Redacted sender
cusbrar2@xxxxxxxxx for DMARC) wrote:
~/config/ and ~/config/non-packaged
over ~/config/packaged and ~/config
Because ~/config/non-packaged was/is supposed to be temporary and only
used by e.g. developers testing software. End-users should get all their
...

Am 15.02.2015 um 23:50 schrieb pete.goodeve@xxxxxxxxxxxx:
On Sun, Feb 15, 2015 at 10:06:09AM -0800, Jim Saxton wrote:
The proper way to accomplish this would have been to leve the
directory system as it was under the home directory but add a
...

On Mon, Feb 16, 2015 at 03:02:51PM -0800, Yourself wrote:
On Mon, Feb 16, 2015 at 09:25:02PM +0100, Axel D?rfler wrote:
On 02/16/2015 07:53 PM, Jim Saxton wrote:
This argument is flawed. One could use B_USER_LIB_DIRECTORY to place
your program's special lib in and still come up with a read-only
directory. Lets face it, like it or not, changing the directory
structure changed the user interface and the appi.
Only in theory -- of course, this is a huge change from before, but you
would place your library in a Software Valet package and tell it to put
...

What exactly is the reason for choosing
~/config/ and ~/config/non-packaged
over ~/config/packaged and ~/config
Is this something to do with having a RO file tree with RW overlays or
something of that nature? Actually, it would seem more logical to me to have a
normal BFS mounted RW with the linux equivalent of loop mounts for the packages
a la DSL packages or Puppylinux environment addons (they used to package the
toolchain as a squashfs I imagine they still do).
From what I understood of the package format it does work as loop mounts with
...

On Mon, Feb 16, 2015 at 08:00:22PM -0500, Augustin Cavalier wrote:
On 2/16/2015 7:58 PM, Pete Goodeve wrote:
Well, no. The whole point/problem is that I have tons of stuff in
~/config/bin, ../add-ons, .../lib, and so on. (Even had ~/config/apps for
a long time for convenience, but that got moved to /boot/common/apps(!))
Then you could have copied all the stuff from ~/config into
~/config/non-packaged.
-Augustin
...

On 2/16/2015 7:58 PM, Pete Goodeve wrote:
Well, no. The whole point/problem is that I have tons of stuff in
~/config/bin, ../add-ons, .../lib, and so on. (Even had ~/config/apps for
a long time for convenience, but that got moved to /boot/common/apps(!))
Then you could have copied all the stuff from ~/config into
~/config/non-packaged.
...

On Mon, Feb 16, 2015 at 07:14:12PM -0500, Augustin Cavalier wrote:
On 2/16/2015 6:02 PM, I wrote:
(I should probably mention that I eventually got most of the environment
I had built up in pre-PM days now working in a PM partition by a horrible
hack! I turned everyting in my old config hierarchy into an hpkg and
installed that!)
Well, ~/config/settings is still writeable so if that's all you wanted
to keep, a tgz would have been enough...
Well, no. The whole point/problem is that I have tons of stuff in
...

On 2/16/2015 6:02 PM, Yourself wrote:
(I should probably mention that I eventually got most of the environment
I had built up in pre-PM days now working in a PM partition by a horrible hack!
I turned everyting in my old config hierarchy into an hpkg and installed that!)
Well, ~/config/settings is still writeable so if that's all you wanted
to keep, a tgz would have been enough...
...

On Mon, Feb 16, 2015 at 09:25:02PM +0100, Axel D?rfler wrote:
On 02/16/2015 07:53 PM, Jim Saxton wrote:
This argument is flawed. One could use B_USER_LIB_DIRECTORY to place
your program's special lib in and still come up with a read-only
directory. Lets face it, like it or not, changing the directory
structure changed the user interface and the appi.
Only in theory -- of course, this is a huge change from before, but you
would place your library in a Software Valet package and tell it to put
it into B_USER_LIB_DIRECTORY, and everything would continue to work.
...