Re: 1.6.0 problems with libguilereadline-v-12 and fix

[prj@po.cwru.edu (Paul Jarc)]

ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>) wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>>> If two seperate packages use the same name for a command,
>>
>> That doesn't happen with slashpackage, because there's a global
>> registry for command names.  If one package is already using a
>> certain name, no one will be able to register it for another
>> package.
>
> By `package,' I mean a software package, not a slashpackage package.

slashpackage packages are software packages.  They are not analogous
to (source or binary) .rpms or .debs - i.e., they are not sources
taken from an author and repackaged by a (different) distributor.
They *are* the source tarballs produced by the authors themselves,
laid out to work with slashpackage.

> That is, if one software suite uses lstr to mean `list translations,'
> and another uses it to mean `last record,' then you're going to have a
> collision, not matter what system you use.

Yes, I know.  I never meant to say otherwise.  But if their authors
participate in the slashpackage registry, that won't happen.  The
authors won't release packages that use names that they haven't
registered.  The benefit of collision avoidance is derived from
authors' participation, not admins'.

> Stow, incidentally, screams if one tries to install two things with
> the same name.  Which is nice.

I'm working on a slashpackage management tool that will do the same,
although it won't be necessary for packages that participate in the
registry.

>> I'm not sure what you mean by `custom.'  The package/install script
>> is included in the package's tarball.
>
> It's something non-standard which someone, somewhere must write.

There is no codified standard here, AFAIK.  There is only the
automake/autoconf de-facto *precedent* - which also has/had to be
written.  Do you think automated tools to create package/install
scripts would be any more difficult?  Offhand, I can think of three
such tools already in existence.

> With slashpackage, if the author hasn't provided it, I must.

slashpackage is not intended for you to take up where the author left
off.  The intent is that the author fully participates.

(It happens that I violate that intent on my machines and install
everything in its own directory under /package.  I've already scripted
this for hundreds of packages, so you don't have to.  For autoconf'ed
packages, it's usually just "./configure --prefix=...; make;
make install".  And just to clarify, I don't do this in the form of a
package/install script.)

> Fortunately, nearly everyone uses GNU autoconf/automake, and those who
> don't typically provide similar install-elsewhere functionality.

Yep - for example, my tool for generating package/install and related
scripts does.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user