Apache RPM Distributions - Was: RPMs for jakarta and xml projects

[GOMEZ Henri <hg...@slib.fr>]

>>I added ecs/rpms, oro/rpms and regexp/rpms but I rather like
>>to see a link to subproject as done for ant, it will avoid 
>
>What is the layout of dist/jakarta/subjproject supposed to look like?
>My impression was that it should follow the pattern of
>dist/httpd, which has all of the tarballs for all of the versions in
>one directory.  If there's some flexibility, then where should the
>subproject link point to?  The obvious choices are either
>/www/jakarta.apache.org/builds/subproject or 
>/www/jakarta.apache.org/builds/sub
>project/release.  The ant link points
>directly to its 1.3 release directory, which I would suggest may not be
>the best thing.  At any rate, my suggestion would be for the link to
>point to /www/jakarta.apache.org/builds/subproject/release and that
>the rpms directory go under that.
>
>Ok, scratch that, I just checked some of the mirror sites and 
>they are not
>picking up the ant stuff because of the symbolic link, so 
>maybe symbolic
>links are a no-go.

If we can't use symlink, we'll have to duplicate datas, which is
allways a bad solution. We could imagine a cron task to recopy
stuff from /www/jakarta.apache.org/builds/ to /dist/jakarta.

Having /www/jakarta.apache.org/builds/subproject/release/rpms is 
a possibility.

Another one could be to have a common sub-dir sharing
all the projects to have a kind of 'Apache distribution' in RPM.

/www/jakarta.apache.org/rpms/subproject/
/www/xml.apache.org/rpms/subproject/

Using that we could ask rpmfind.net, the major RPM indexer today, to
start index. rpmfind allways keep the latest release in it's indexing
system.

ie: 

/www/xml.apache.org/rpms/ant/ant-1.2.1.noarch.rpm
/www/xml.apache.org/rpms/ant/ant-1.2.2.noarch.rpm
/www/xml.apache.org/rpms/ant/ant-1.3.1.noarch.rpm

rpmfind.net will only show the ant-1.3.1 even if you still
have the 1.2.1 , 1.2.2 and 1.3.1 is the subdir.

But the optimum solution is to use the 'distribution concept',
ie having all the related projects (and same level) projects
in the same distro :

/dist/rpms/ApacheDistrib1/

Loaded with :

ant 1.3.1, oro 2.0.1, regexp 1.2, tomcat 3.2.1, xerces 1.3.1, xalan 2.0.1,
cocoon 1.8.2...

All these tools are known to interoperate (ie avoiding problem with xerces
1.2 and xalan 2.0).

This distro could be use immediatly by new users, they will be sure that all
the packages
will works with others and their system will be configured depending on
modules installed
(ie: adding cocoon rpm will setup accordingly tomcat).

The distro will be loaded with binaries and manuals (I use to make a
xxx.noarch.rpm and 
xxx-manual.noarch.rpm). The manual (ie javadocs) are put in the DocumentRoot
of their
web-server.

The success of Linux started when rookies could started to use Redhat
distributions 
(and others later) which garanties them a set of working and compatible
components.

May be time to do the same for Apache jakarta and xml projects, and of
course the
httpd project.

I even have a Apache 2.0 beta16 RPM ready (default port on 8092), and 
which works in parallel with Apache 1.3 since it have its command and 
paths suffixed by 2 :

httpd2, ab2, apxs2, /home/http2, /var/log/httpd2......

I'm waiting for comments and sorry for the spread on 3 lists but I feel
everybody (xml, jakarta, commiters) is concerned :)





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: Apache RPM Distributions - Was: RPMs for jakarta and xml projects

[Brian Behlendorf <br...@collab.net>]

> >Ok, scratch that, I just checked some of the mirror sites and they
> >are not picking up the ant stuff because of the symbolic link, so
> >maybe symbolic links are a no-go.

I would recommend against symlinks at any rate; not only do they cause
mirrors/caches to duplicate data, they're usually a sign of sloppy design.
They're useful primarily as a crutch to aid in migrations.  I would
re-examine the principles that suggest that duplicate URL's to the same
data is a good idea.

> If we can't use symlink, we'll have to duplicate datas, which is
> allways a bad solution. We could imagine a cron task to recopy
> stuff from /www/jakarta.apache.org/builds/ to /dist/jakarta.

Seems to me that anything under a URL with "builds" in it should be
considered different than "releases" - builds are things that are either
automatically generated from cron or candidates built by humans to be
considered releases, but once declared as an actual end-user release,
should be put somewhere else.

MHO, of course.

	Brian




---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Apache RPM Distributions - Was: RPMs for jakarta and xml projects

[Brian Behlendorf <br...@collab.net>]

> >Ok, scratch that, I just checked some of the mirror sites and they
> >are not picking up the ant stuff because of the symbolic link, so
> >maybe symbolic links are a no-go.

I would recommend against symlinks at any rate; not only do they cause
mirrors/caches to duplicate data, they're usually a sign of sloppy design.
They're useful primarily as a crutch to aid in migrations.  I would
re-examine the principles that suggest that duplicate URL's to the same
data is a good idea.

> If we can't use symlink, we'll have to duplicate datas, which is
> allways a bad solution. We could imagine a cron task to recopy
> stuff from /www/jakarta.apache.org/builds/ to /dist/jakarta.

Seems to me that anything under a URL with "builds" in it should be
considered different than "releases" - builds are things that are either
automatically generated from cron or candidates built by humans to be
considered releases, but once declared as an actual end-user release,
should be put somewhere else.

MHO, of course.

	Brian




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org