[haiku-development] Re: AW: Re: Package Management
- From: pete.goodeve@xxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 1 Sep 2014 15:05:35 -0700
On Mon, Sep 01, 2014 at 09:59:25AM +0200, Axel Dörfler wrote:
> Fredrik wrote:
> > 2014-08-31 22:31 skrev pete.goodeve@xxxxxxxxxxxx:
> > > And yes, the first thing I had to do to get some of the stuff I use
> > > transferred to PM was to set up my own /boot/common.
> > If I recal correctly common was removed just before PM was introduced.
> > It was discussed a lot but was not adding any vital function that can be in
> > home or system. Now with PM this are less neede. The only mention of
> > needing /boot/common was if a company would need to use it, they can
> > now use PM instead and make there own repository :)
>
> You got that wrong. The reason for a /boot/common was a clean separation of
> system files vs. other installed software (for all users).
> However, it turned out that there simply is no such clean separation; you'd
> have dependencies in both directions which makes the whole thing unfeasible.
I don't know if anyone actually read my suggestion. (:-/) I'm not proposing
that *anything*
be moved out of system back into common, oir that common should be part of the
package
mechanism. I see it needed as a bridge for already developed software that
expects it.
Dependecies from system back to common should never happen.
As a specific case, over a year ago I spent several months porting the audio
synthesis
suite Csound. Being a cross-platform program, it adopted the scheme of
hard-coded default
paths for each platform, so I simply follwed suit and -- assuming that common
was the proper
place for things linke that and it would be around forever -- I used
"/boot/common/lib" as the base.
Then, a few months later, along comes PM, and common is gone! *I* have csound
running
in PM (without rewriting anything) but it needed quite a few hacks that I
wouldn't expect
anyone else to have to do. If a non-packaged common, with lib and bin in their
search paths,
was standard, the package would still work without hassle.
>
> > > But this is the problem, isn't it? There is no discussion -- only
> > > 'fiat'.
>
> Please consult the list archives before making stupid claims like this. The
> world doesn't just stand still when you don't look.
Yes, I apologize. I was reacting to what I felt was a high-handed comment by
Augustin.
I'm well aware of the discussion, had it archived, and in fact was re-browsing
it before
your (and Ingo's) response.
> I really tried to defend /boot/common, but in the end, I had to give up on
> the idea, as it just couldn't work out.
I think it would be fine, for the purpose I'm suggesting. It wouldn't give any
PM advantages,
but old things would still work.
What does sound more problematic is my suggestion for a "local" hierarchy,
which I think
is pretty much what you were envisaging common to be. If I understand it
right, a package
can only handle dependencies within its own heirarchy. So any system depencies
in a
local package would have to be resolved manually. Can a package installed in a
non-system
location at least detect if a system dependency is satisfied?
If not, that seems a bit of a problem... And doesn't the same apply to a PM
~/config?
And also, as I said before, I at least think ~/config should be restored to
read/write, so
that old things work. Add a new packaged hierarchy in home. After all, any
packaged
stuff has to be written fresh, so it doesn't have to be in "config".
What's worrying me is seeing another Linux emerging, where everything gets
lumped
into the same untangleable directory. My Ubuntu /usr/bin has 1790 items with
mostly
cryptic names. Haiku's ability to let a user put apps or anything else whare
they
think appropriate has always been very valuable to me. I don't want to see
system
just become a pile of miscellaneous stuff!
-- Pete --
Other related posts:
- » [haiku-development] Re: AW: Re: Package Management - pete . goodeve
