Re: [DotGNU]Fitzix Free Software Audit project

[Barry Fitzgerald]

Ahh, great... thanks for getting back to  me so quickly :)

Well, to start with, I need a new home.  The site that I've been testing
for some time (freeshell.org) has been going up and down from time to time
so I don't think that that's a good thing.  I'm even contemplating moving
my mailing list e-mail to another shell, should I be able to get one
somewhere.  But, that's a logistics problem and I'll deal with it a little
bit later on.

The first thing to deal with is the site.

I envision a site which has the package list, an audit section concerning
style of compilation (if there's a configure script, if it's gnu autoconf
based, make file attributes, etc...), config options, changes to the
package/configuration scheme in order to make the package FHS/LSB
complient (actually, this is a bigger problem than you'd think)... etc...
I want it to be a place where people can go for all information concerned
with that package.

The site must have the directory, a section for developer/user forums for
each package, a section for discussion based on each package in an essay
form, etc... I think that for this to work I'll need teams to deal with
each package.  This is huge when you think about it.  But, a good place to
start might be with an application (It can even be shellscript) which asks
questions and places the answers into a pre-formatted HTML file to be
uploaded into the system.

However, to get there we have to decide on what attributes should be
considered.  As a start I will offer up these options:

        -package name
        -requirements
        -dependencies
        -configure based? (autoconf)
        -Makefile based?
        -Installation instructions (generic)
        -configure help analysis (you'd be surprised)
        -Makefile gotchas
        -Compiling gotchas
        -Installed file list (generic)
        -FHS compliance changes (http://www.pathname.com/fhs)
        -LSB considerations (since the LSB is so new, I'm only considering
this over the past few days.)

This is just the beginning.  We could kick it up a notch and try to
understand the workings of various packages from a tutorial level.  That
might assist with modifying packages and would also draw more people to
the directory portal.

Also, I'm not so much worried about dotgnu forking as I am about subtle
differences between packages/distributions.  Let's say that debian has a
modified version of the glibc, and something odd happens when trying to
run one of our patches, it'd be nice to be able to track this stuff in a
localized system.  Hell, this type of thing would be great for ALL
projects.  Also, we might want to know what version of, let's say
XFree86 for example, is installed on any given system by default.  If we
modify X 4.1.0, for example, and a person is running a Red Hat 6.2 system,
we're going to have to address various different concerns that that person
may deal with in order to make this transition smooth.

But, there's actually a greater advantage.

Having a package audit will allow us to determine which packages are in
greater distribution and which ones are more suited to these
modifications.  It's just an idea, but it's something that this community
needs sorely.


address@hidden
SDF Public Access UNIX System - http://sdf.lonestar.org

On Fri, 6 Jul 2001, Myrddian wrote:

> Well considering that DotGNU could be considered a whole bunch of subprojects
> the possiblility of forking can be quite high, however considering that there
> are too many of these sub projects, a project forking (well for DtGNU) to be 
> completely
> forked would have to require a lot of work on the part of the people who want 
> to fork it
>
> How many forkers does it take to fork if a forker could fork code. (Sorry I 
> just took  a look
> at my paragraph)
>
> However considering that each Dsitributor of GNU/Linux might want  a different
> or implement a different "sub-project" of DotGNU and not provide the end
> user with the whole system. For example GCC should GCC generate DotGNU 
> bytecode
> and a developer wants to use that and teh distributor provides a version of 
> GCC
> which does not, then we can see a problem.
>
>
>
> I can see the idea with a Project/Software Directory for DotGNU could help 
> users
> and developers.
>
> So what do you wish to do?
>
>
>