[haiku-development] Re: Package Management [was Re: What's the status of Haiku?]
- From: Pete Goodeve <pete.goodeve@xxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 30 Aug 2014 17:54:59 -0700
On Sat, Aug 30, 2014 at 12:00:07PM +0200, Stephan A?mus wrote:
> Am 30.08.2014 03:31, schrieb Pete Goodeve:
> >
> >As I said, I have no memory of this poll. [Undoubtedly me...!] Can
> >someone provide a link to the archive
> >or at least an approximate date, so I can look back at it? Thanks.
>
> The vote was *ages* ago, the results are preserved here:
>
> https://dev.haiku-os.org/wiki/FutureHaiku/Features
> Prop #30 and #31
OK -- that explains why I never saw it. I've never really learnt my way around
the wiki so I guess I didn't even know of its existence. Thanks.
>
> Some people talk as though this has suddenly appeared from nowhere
> or wasn't thought through enough (!). Or they mention the package
> management in passing as if it is some kind of "common wisdom" among
> Haiku users that it sucks or is overly complicated. I find that so
> ignorant and uninformed.
In my case, I knew PM was coming. What was not impressed on me
*at all* was that there would be any disruption to my long-established
way of working. When that hit, yes, I was irritated.
>
> It happened several times now that some vocal opponents of PM have come
> to grasp the beauty of what has been accomplished. I think our PM
> solution is one of the very, very few things left that make Haiku
> relevant. It is something that was possible to pull off since we have
> complete control over the whole OS, and I think it is something that
> other projects will envy in time.
Please understand that I'm not in any way against PM! It's elegant,
works as it should, and solves the problems people have mentioned.
I just think it could have been implemented *without* disruption.
(And still could, without messing up what's been done since.)
I'm a little disappointed that no-one has commented on my suggested
structure in my previous post. Let me restate it a bit with some
correction and explanation.
The /boot/system hierachy is ideally suited to PM and should be
set up exactly as it is now. However, I don't think *non* system stuff
should keep getting jammed into system. It's very helpful to have
a distinction between the "standard" core of Haiku, and apps and
data the user may personally want to have on their machine.
OTOH, I don't think ~/config should be packaged. That breaks too
much legacy stuff. And if the eventual goal is multiuser, non-system
items intended fo all users shouldn't go there anyway. So I suggest
a "common-like" packaged hierarchy should be added at the top level
-- maybe "/boot/local" (in analogy to ***x's "/usr/local" which is very
handy for exactly that purpose). (there could well be a similar
"~/local" tree for really personal stuff -- replacing the PM'd config.)
Additionally, /boot/common should be restored -- unpackaged.
Personally -- understaning it was a standard location for storing
things that I wanted generally available and easily locatable --
I made extensive use of it. A "...common/apps" folder has been
very useful to keep all the frequently used apps I've downloaded.
I don't want them all stuffed into the system/apps area -- I want
them to be separate. And I added a "common/scripts" folder
to store all my xicon scripts so I know exactly where to find them.
When common/bin was in the path all my local command-line
stuff went there. I suppose a "local/non-packaged" area would be
equivalent in many ways, but again I see legacy compatibility as
important.
("common" is *not* a substitute for system/non-packaged! The
latter should be reserved for when custom pieces of the system
have to be added. For instance my revised HDA driver goes there.)
In summary:
boot:
system [packaged as now but reserved for really system stuff]
local [added packagefs hierarchy for non-system]
common [unpackaged -- old-style hierarchy]
home
config [once again read-write]
local [packaged for personal stuff]
Reasonable?
-- Pete --
Other related posts:
