The Testing Area :: March extensions

There has been a few external personal repos used already, and they were fine due to the fact the submitters posted links here on the forum and were eventually posted on the official site. My guess is that this was also used for convenience, as uploading attachments on email can have problems.

It sounds like having prior community approval might be complicated... and time consuming, but I can see how it could work.

On the subject of automatic testing, I was thinking of a quick 'surface' scan like script, similar to what WDef has in mind. I guess those extensions could always wait in testing/ but certain things would be found much faster if something could always check for those things. I was wondering if something could be done on the repos' server, but I suppose that probably wouldn't be allowed.

As for thorough inspections, they can be left to the community. I may have time for that sometime soon, but I still need to see how extensions work for 4.x :P

EDIT: removed comment about mydsl.es.org due to misunderstanding

I think WDef's suggestion for enhanced declobbler script as an initial test of appropriateness is a very good idea and would be most welcomed. I would post it so that extension builders could download and self-test as well as I could run before posting.

Quote (roberts @ Mar. 28 2008,18:42)

Yes, that's what I've been wishing I had. (Apologies for any problems.)

I'm not up to the level of the ten other guys who are active on this board, but I'm trying to climb the learning curve.

I found the line of bash code and see what people mean.

Do I understand correctly that packages can be forced into /opt via a script?

If so, can anyone point me toward an easy example so I can fix the problems.

./configure --prefix=/opt/package

works every time..

Newby-

Do you have a copy of the DSL book? It covers all the details about building the different extension types. It is a good idea for anyone to get it and read it before submitting any extensions, especially .tar.gz and .uci ones. Also, become familiar with building from source. Reading through Linux From Scratch would help a lot. I bought that book too and read it on vacation when I needed a Linux fix.

This is not the right section, and this is also covered in other places, so I will be brief. When I install into /opt, "./configure --prefix=/opt/package && make && make install" is the first step. I copy the resulting /opt/package/lib/pkgconfig/package.pc file (if there is one) to /usr/lib/pkgconfig and 'export PKG_CONFIG_PATH=/usr/lib/pkgconfig' if I have multiple libraries or apps that will depend on each other in the extension. Without pkgconfig files, ./configure options may be used to tell an app where the libraries are. There are other steps like exporting library paths and such that can be needed, but this is a basic starting point. The LFS process involves installing things in non-standard places and is a good resource on compiling and package building.

Practice building and installing stuff and getting familiar with the details of making an extension of what you built. Build a few extensions, use them a while, and when you know you have a keeper submit it.

EDIT: I see Curaga beat me to it with /opt/package while I was writing.

Next Page...
original here.