apt based package dist for guile?

apt based package dist for guile?

[Nic]

Has anyone ever considered setting up an apt package system for guile?

I think the FSF would probably be happy to host it on savannah if we
asked them nicely.

Such a system would be similar to CPAN. But much simpler.

Any thoughts?



-- 
Nic Ferrier
http://www.tapsellferrier.co.uk



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

Re: apt based package dist for guile?

[MJ Ray]

Nic <nferrier@tapsellferrier.co.uk> wrote:
> Has anyone ever considered setting up an apt package system for guile?

Do you mean something other than http://packages.debian.org/guile* then?




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

Re: apt based package dist for guile?

[Nic]

MJ Ray <markj@cloaked.freeserve.co.uk> writes:

> Nic <nferrier@tapsellferrier.co.uk> wrote: 
> > Has anyone ever considered setting up an apt package system for guile? 
>  
> Do you mean something other than http://packages.debian.org/guile* then? 

Yes I do.

I mean something exclusively for guile packages and probably
something outside of the Debian project.

Doing the search you suggested lists versions of guile as well as
packages. There isn't a specific debian category for guile packages.

I just think it would be a cool way of achieving the same things CPAN
does.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk



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

Re: apt based package dist for guile?

[Thamer Al-Harbash]

On Mon, 4 Aug 2003, Nic wrote:

> I just think it would be a cool way of achieving the same things CPAN
> does.

I'd sooner stick a needle in my eye than use a CPAN like system.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F
   "to understand recursion first one must understand recursion"


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

Re: apt based package dist for guile?

[Joshua Judson Rosen]

[-- Attachment #1.1: Type: text/plain, Size: 398 bytes --]

On Mon, Aug 04, 2003 at 12:31:53PM -0400, Thamer Al-Harbash wrote:
> On Mon, 4 Aug 2003, Nic wrote:
> 
> > I just think it would be a cool way of achieving the same things CPAN
> > does.
> 
> I'd sooner stick a needle in my eye than use a CPAN like system.

Why is that?

-- 
"Telling the truth to people who misunderstand you
 is generally promoting a falsehood, isn't it?" --A. Hope

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

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

Re: apt based package dist for guile?

[Thamer Al-Harbash]

On Tue, 5 Aug 2003, Joshua Judson Rosen wrote:

> On Mon, Aug 04, 2003 at 12:31:53PM -0400, Thamer Al-Harbash wrote:
>
> > I'd sooner stick a needle in my eye than use a CPAN like system.
>
> Why is that?

Sorry for the knee jerk reaction. This isn't the forum to knock
other packaging systems.

There are too many reasons to list. I could probably discuss the
pros and cons for hours. Suffice it to say that for operating
systems which you want to ship to users and keep up to date
yourself, using a packaging system with automatic dependency
tracking is great.

For a programming environment this is not the case. Making this
inpersonal, automatic, and "always up to date" is not necessarily
good. You go from shipping a really nice Scheme
interpreter/library to shipping a virtual plastform.

My own feeling is that there should be a maintainer or two that
keeps track of stable guile software and keep a directory up to
date. This process can also be automated by having programmers
submit their projects for listing. We already have freshmeat, and
the Free Software Directory. These two directories can serve this
purpose well enough as it is.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F
   "to understand recursion first one must understand recursion"


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

Re: apt based package dist for guile?

[rm]

On Tue, Aug 05, 2003 at 01:29:28PM -0400, Thamer Al-Harbash wrote:
> On Tue, 5 Aug 2003, Joshua Judson Rosen wrote:
> 
> > On Mon, Aug 04, 2003 at 12:31:53PM -0400, Thamer Al-Harbash wrote:
> >
> > > I'd sooner stick a needle in my eye than use a CPAN like system.
> >
> > Why is that?
> 
> Sorry for the knee jerk reaction. This isn't the forum to knock
> other packaging systems.
> 
> There are too many reasons to list. I could probably discuss the
> pros and cons for hours. Suffice it to say that for operating
> systems which you want to ship to users and keep up to date
> yourself, using a packaging system with automatic dependency
> tracking is great.

Are you refering to Debian's apt system (authomatic 'up-to-date')
or to CPAN (Perl's package archive)?
The two systems are arather different, esp. when it comes to
the "issues" you mention.

> For a programming environment this is not the case. Making this
> inpersonal, automatic, and "always up to date" is not necessarily
> good. You go from shipping a really nice Scheme
> interpreter/library to shipping a virtual plastform.
> 
> My own feeling is that there should be a maintainer or two that
> keeps track of stable guile software and keep a directory up to
> date. 

The idea of 'stable' is rather what apt tries. You do _not_ get
software that is "up to date" but rather a stable snapshot, that
sometimes can be (and often is) rather outdated (but stable).
CPAN is just the other half of your suggestion: a list/directory of 
stable packages/modules (and by no means a platform).

> This process can also be automated by having programmers
> submit their projects for listing. We already have freshmeat, and
> the Free Software Directory. These two directories can serve this
> purpose well enough as it is.

The one tempting thing about CPAN (and apt, here's where they meet)
is the simple, unified build/install process -- either 'apt-get install foo'
or CPAN's 'download / perl Makefile.PL / make / make install' process.
[or, from the developer's side: a build system that helps to create
 a .dpkg or even a module that wraps the build/install process like
 MakeMaker.pm]

 Ralf Mattes

> -- 
> Thamer Al-Harbash
> GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F
>    "to understand recursion first one must understand recursion"
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user


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

Re: apt based package dist for guile?

[Paul Jarc]

rm@fabula.de wrote:
> The one tempting thing about CPAN (and apt, here's where they meet)
> is the simple, unified build/install process -- either 'apt-get install foo'
> or CPAN's 'download / perl Makefile.PL / make / make install' process.

Perl's MakeMaker means that the build system for a Perl module is the
same as that of other Perl modules, but it's gratuitously different
from that of all other packages.  There's no reason that a package's
build system should be based on the fact that it happens to be an
extension of a particular scripting language.  It's better to stick
with an existing build system that people already know (e.g.,
autoconf, or whatever you would normally use for anything else).  It
makes sense to put together some rules (m4 macros for autoconf, or
whatever) that can be reused for all modules for a particular
scripting language, but there's no reason to stick the installing user
with a different interface.


paul


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

Re: apt based package dist for guile?

[Nic]

prj@po.cwru.edu (Paul Jarc) writes:

> rm@fabula.de wrote: 
> > The one tempting thing about CPAN (and apt, here's where they meet) 
> > is the simple, unified build/install process -- either 'apt-get install foo' 
> > or CPAN's 'download / perl Makefile.PL / make / make install' process. 
>  
> Perl's MakeMaker means that the build system for a Perl module is the 
> same as that of other Perl modules, but it's gratuitously different 
> from that of all other packages.  There's no reason that a package's 
> build system should be based on the fact that it happens to be an 
> extension of a particular scripting language.  It's better to stick 
> with an existing build system that people already know (e.g., 
> autoconf, or whatever you would normally use for anything else).  It 
> makes sense to put together some rules (m4 macros for autoconf, or 
> whatever) that can be reused for all modules for a particular 
> scripting language, but there's no reason to stick the installing user 
> with a different interface. 

Are you saying people don't understand apt/rpm/etc...?

The thing that I was advocating about APT was the command line access
to a directory of "packages". A common directory for tarballs would
be a first step forward because we could write some nice tools to
front end it.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk



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

Re: apt based package dist for guile?

[Paul Jarc]

Nic <nferrier@tapsellferrier.co.uk> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> Perl's MakeMaker means that the build system for a Perl module is the
>> same as that of other Perl modules, but it's gratuitously different
>> from that of all other packages.
>
> Are you saying people don't understand apt/rpm/etc...?

No.  Those types of things repackage existing code.  No matter what
build system I choose for packages I publish, someone else can come
along and wrap it up in a .deb or .rpm.  But users who install my
package from my source tarball will get the same kind of interface for
the build system, regardless of whether the package is a Guile
extension or something else entirely.  (It happens that I also think
that apt/rpm/etc. are trying to solve a problem that can and should be
solved upstream by the package maintainers themselves, but that's
anoter topic.)

> The thing that I was advocating about APT was the command line access
> to a directory of "packages". A common directory for tarballs would
> be a first step forward because we could write some nice tools to
> front end it.

As with the build system, I see no reason to restrict such a directory
to Guile extensions.  Make a directory to accomodate all packages, and
let users query it with filters like "show me only Guile extensions",
"show me only window managers", etc.

Ideally, this would be integrated with slashpackage:
<URL:http://cr.yp.to/slashpackage.html>


paul


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

Re: apt based package dist for guile?

[Thamer Al-Harbash]

On Tue, 5 Aug 2003, Paul Jarc wrote:

> (It happens that I also think
> that apt/rpm/etc. are trying to solve a problem that can and should be
> solved upstream by the package maintainers themselves, but that's
> anoter topic.)

Sadly this is very true. I wish I got a penny for every package
maintainer who maintained his own set of patches and never
notified the author of the fixes that were made.

> Ideally, this would be integrated with slashpackage:
> <URL:http://cr.yp.to/slashpackage.html>

The problem with slashpackage, although it's a great idea, is
that it ships to be used in a specific directory. Symlinking
tricks aside, there are enough people who don't want a /package
directory and that makes the adoption of slashpackage very
slow. DJB created an alternate universe as opposed to a flexible
set of tools.

I feel guile shouldn't make the mistake of trying to create an
alternate universe. GNU autoconf is a darned good tool right now
for source distribution.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F
   "to understand recursion first one must understand recursion"


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

Re: apt based package dist for guile?

[MJ Ray]

Nic <nferrier@tapsellferrier.co.uk> wrote:
> I mean something exclusively for guile packages and probably
> something outside of the Debian project.

It would be more useful to have a cross-implementation system for
extension modules.  Something like an offspring of SLIB and CPAN,
but avoiding the gnarly bits of both.  Such a solution will almost
inevitably be a 90% one, but better than the 0% one we have now.

When I last looked at this, the lexmod code at
http://www.bloodandcoffee.net/campbell/code/ and some way of downloading
the "most appropriate" version for an implementation seemed like a good
idea to me.

Now, cue the flames from the guile fans who can't believe any other
implementation is worth using for anything, or that the guile module
system should be added to all others regardless of their differences.

-- 
MJR/slef   My Opinion Only and possibly not of any group I know.
      http://mjr.towers.org.uk/   jabber://slef@jabber.at



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

Re: apt based package dist for guile?

[Paul Jarc]

Thamer Al-Harbash <tmh@whitefang.com> wrote:
> On Tue, 5 Aug 2003, Paul Jarc wrote:
>> Ideally, this would be integrated with slashpackage:
>> <URL:http://cr.yp.to/slashpackage.html>
>
> The problem with slashpackage, although it's a great idea, is
> that it ships to be used in a specific directory.

That property is a problem only aesthetically.  On technical grounds,
it's a major win.  When there is more than one possible location for a
file, there is a risk of finding the wrong file, etc.
<URL:http://cr.yp.to/slashpackage/studies.html>

> Symlinking tricks aside, there are enough people who don't want a
> /package directory and that makes the adoption of slashpackage very
> slow.

Yes, it will be slow.  But hopefully, in time its advantages will be
better understood, and people will develop different aesthetic tastes.

> DJB created an alternate universe as opposed to a flexible set
> of tools.

It's "alternate" in the sense of being different, but you aren't
forced to reorganize your whole system if you just want to install one
slashpackage-oriented package.  And FWIW, the tools I've created to
work with /package will also work with any path whose contents play by
the same rules: <URL:http://multivac.cwru.edu./sptools/>


paul


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