Re: Conversion to /package

Thomas Schwinge <[email protected]> wrote:
> Paul Jarc <[email protected]> schrieb:
>> But if there's a switch that can be used by a maintainer to produce
>> either a traditional tarball or a slashpackage tarball, that'll
>> make it much easier for more developers to start using
>> slashpackage.
>
> I can't follow you here:
> Do you mean that the package's maintainer should decide if the package
> will be installed in /package before it ist distributed

Sort of.  Ideally, the maintainer could produce two types of tarballs:
one traditional, and one for slashpackage, complete with package/*
scripts, etc.  Then users who like slashpackage could choose that
tarball, and the maintainer could see what portion of the users prefer
slashpackage.

There is the possibility that this could make life harder for other
packages that depend on this package, but as long as symlinks are
provided within the package directory (lib -> library, bin -> command,
etc.) so that the internal hierarchy is the same, then the situation
won't be any worse than what we have now, since users can already do
"./configure --prefix=...".

> or do you mean that the user will be able to decide where to install
> via some ./configure switch (like Dan suggested)?

That could also be useful as a bare-bones first step.  But in either
case, if the package maintainer is distributing a tarball that (one
way or another) installs into /package/..., then it should use a
registered name (or an appropriate name in /package/host/).  So the
category path has to be specified by the maintainer in the
configure.ac file; it can't be hard-coded in autoconf as
/package/misc/spf/ or anything else.

> I wanted to install "foreign" packages in /package like you do with
> sp-foreign.
> I didn't want to create a new hierarchy for doing the same thing a
> different way.

You are doing it slightly differently, though, since you change the
subdirectory names (bin => command, etc.).  It's possible this could
break something, if some piece of code expects to find, e.g.,
/package/misc/spf/strace/bin/strace, after it sees that
/package/misc/spf/strace is there.

> But since I'm not a maintainer of any package, my patches were only a
> "proof of concept".

Still a good starting point, I think.

> I'm very sure that I'm not going to bring my patches up at the state
> they are at current.
> We should present something fully grown to them.

Well, not necessarily fully-grown.  After all, we are not the autoconf
maintainers, and even if they decide to support slashpackage, they may
implement the autoconf code differently from how we would.  So the
more work we do without talking to them, the more is likely to be
wasted effort that will be replaced with something different.  But I
agree it might be useful to have something more concrete than what
there is now.


paul