Re: Conversion to /package

Thomas Schwinge <[email protected]> wrote:
> Another possibility I was thinking about was patching the programs that
> make these software packages use the paths they use: the GNU auto*-suite.

This is great.  I was planning on eventually talking to the auto*
maintainers to try to convince them to add slashpackage capabilities,
but a patch is better than a request.  Of course, they won't accept it
if it means that auto* will no longer be useful for the traditional
mode of operation.  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.  The barrier to entry is lower, so there will be
more experimentation, and eventually more conversion.

> sp-links /package/misc/spf/strace/command /command &&

I don't think that's a good path to use.  I've registered misc/spf/
for my slashpackage-foreign project, for installing "foreign" packages
in /package.  Your work looks like it would be most useful to help
more developers make "native" slashpackage releases (possibly in
parallel with traditional releases).  Anyone slashpackaging their own
software should register a name for it outside of misc/spf/.  Do your
auto* modifications allow the configure.ac or whatever to specify the
full /package/... path?

> But the problem with this installation method is that there are too many
> GNU packages out there that use and require too many different versions
> of the GNU auto*-tools to let this method be practicable.

It would definitely help for new development, though, which is
certainly better than nothing.  I encourage you to bring this up on
the relevant GNU lists (or I can, if you'd rather not stir up that
hornet's nest) - gnu-misc-discuss, probably, along with autoconf,
automake...  (libtool? autogen? which code did you have to change?)


paul