Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Pacman Development (http://www.linux-archive.org/archlinux-pacman-development/)
-   -   Splitting packages in makepkg (http://www.linux-archive.org/archlinux-pacman-development/106126-splitting-packages-makepkg.html)

Allan McRae 06-13-2008 12:48 PM

Splitting packages in makepkg
 
NOTE: This is a discussion about the technical implementation of the
ability to build split packages in makepkg. DO NOT reply if all you
want to say is splitting packages is a bad thing. Just because makepkg
can split packages does not mean Arch will start splitting everything up
into binary/header packages. I can say with great certainty that that
will never happen.


I was going to wait until 3.2 was out the door to start implementing the
ability to split packages but there has been enough activity on the bug
tracker lately that I thought this discussion would be timely.

There have been several proposals for building split packages with
makepkg. See:
http://bugs.archlinux.org/task/7144
http://bugs.archlinux.org/task/7982
http://bugs.archlinux.org/task/8187

The question is how best to implement this. I can not see any other way
than having a "split" array listing the names of the split components,
so the need for this is almost a given.

With input from the bug reports, I see two possible ways to implement
this (in the PKGBUILD):

1) The KDEMod style (FS#7982), where each package has its own install
function. e.g.

base_install() {
# do install stuff
}

gui_install() {
# override pkgname etc
# do install stuff
}


2) A "package" function with a case statement. e.g.

package() {
case "$1" in
"base" )
# do install stuff
;;
"gui" )
# override pkgname etc
# do install stuff
;;
esac
}

I am kind of torn here... I like the idea of having a single function
but the syntax is slightly more complex. Although the multi function
version is already in use, that should not be a limiting factor - we
should be striving for technical elegance rather than accepting the
current situation.


The second point I would like to bring up is based on the suggestion in
FS#8187. In it I suggested having separate subdirectories where each
sub-package is installed into. This would be a benefit because it would
not require the clearing of the pkg directory after each sub-package
install as in the current KDEmod implementation. I see this would be a
definite help when bugfixing a PKGBUILD as you can easily browse the
installed files. It would also mean that we could keep the repackage
option working.

This could be implemented with either method by setting the pkgdir
variable before calling whichever package function is chosen. But it
would require the forcing of the use of $pkgdir rather than
$startdir/pkg as that would fail.


So people, what are you opinions on the ideas above? These are just the
choices I can currently see so don't feel limited to only commenting on
them. At this stage I would not worry about the actual naming scheme of
functions etc, just the implementation. So please discuss (after going
back and reading the top paragraph...).

Allan




_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Mark Constable 06-13-2008 01:42 PM

Splitting packages in makepkg
 
This is purely FWIW and I am *not* suggesting it be considered as the
canonical way to provide split packages. It provides a test case for
one approach that I have been using for months without requiring any
patches to makepkg. Probably best demonstrated as a psuedo example...

# cat PKGBUILD
pkgname=qt-copy
pkgver=4.4.0
... etc

build()
{
# regular main package build instructions

build_doc
build_dev
}

build_doc()
{
mv $pkgdir $pkgdir.orig && mkdir $pkgdir || return 1
mkdir -p $pkgdir/{usr/bin,usr/share/doc}
mv $pkgdir.orig/usr/share/doc/* $pkgdir/usr/share/doc

cd $startdir
makepkg --asroot -R -p PKGBUILD.doc
rm -rf $pkgdir
mv $pkgdir.orig $pkgdir
cd $srcdir/$pkgname-$pkgver
}

build_dev()
{
mv $pkgdir $pkgdir.orig && mkdir $pkgdir || return 1
mkdir -p $pkgdir/{usr/bin,usr/include}
mv $pkgdir.orig/usr/include/* $pkgdir/usr/include
# lazy
mv $pkgdir.orig/usr/bin/* $pkgdir/usr/bin # mv all bins to dev
mv $pkgdir/usr/bin/qtconfig $pkgdir.orig/usr/bin # mv qtconfig back
mv $pkgdir/usr/bin/qdbus $pkgdir.orig/usr/bin # mv qdbus back

cd $startdir
makepkg --asroot -R -p PKGBUILD.dev
rm -rf $pkgdir
mv $pkgdir.orig $pkgdir
cd $srcdir/$pkgname-$pkgver
}

------------------------------

# cat PKGBUILD.doc
pkgname=qt-copy-doc
pkgver=4.4.0
pkgrel=$(date +%Y%m%d)
pkgdesc="The Qt Gui Toolkit Documentation"
url="http://www.trolltech.com/products/qt"
arch=(any)
source=($pkgname-$pkgver.tar.gz)
license=(GPL)

------------------------------

# cat PKGBUILD.dev
pkgname=qt-copy-dev
pkgver=4.4.0
pkgrel=$(date +%Y%m%d)
pkgdesc="The Qt Gui Toolkit Development Files"
url="http://www.trolltech.com/products/qt"
arch=(i686 x86_64)
source=($pkgname-$pkgver.tar.gz)
license=(GPL)


--markc

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

"Sergej Pupykin" 06-13-2008 04:24 PM

Splitting packages in makepkg
 
Hi,

I like following idea:

PKGBUILD
------------------
pkgname=foobar
pkgver=1.0
pkgrel=1
subpackages=(dev doc)

....

build() {

.....

make DESTDIR=$startdir/pkg install
...
make DESTDIR=$startdir/pkg-dev install
...
make DESTDIR=$startdir/pkg-doc install
}
---------------

According to subpackages array makepkg creates 3 dirs:
- $startdir/pkg (as usually)
- $startdir/pkg-dev
- $startdir/pkg-doc

PKGBUILDs build function install all stuff into them

And then, makepkg creates 3 packages:

$pkgname-...pkg.tar.gz
$pkgname-dev-...pkg.tar.gz
$pkgname-doc-...pkg.tar.gz

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Xavier 06-14-2008 07:22 PM

Splitting packages in makepkg
 
Allan McRae wrote:
>
> I was going to wait until 3.2 was out the door to start implementing the
> ability to split packages but there has been enough activity on the bug
> tracker lately that I thought this discussion would be timely.
>
> There have been several proposals for building split packages with
> makepkg. See:
> http://bugs.archlinux.org/task/7144
> http://bugs.archlinux.org/task/7982
> http://bugs.archlinux.org/task/8187
>
> The question is how best to implement this. I can not see any other way
> than having a "split" array listing the names of the split components,
> so the need for this is almost a given.
>
> With input from the bug reports, I see two possible ways to implement
> this (in the PKGBUILD):
>
> 1) The KDEMod style (FS#7982), where each package has its own install
> function. e.g.
>
> base_install() {
> # do install stuff
> }
>
> gui_install() {
> # override pkgname etc
> # do install stuff
> }
>
>
> 2) A "package" function with a case statement. e.g.
>
> package() {
> case "$1" in
> "base" )
> # do install stuff
> ;;
> "gui" )
> # override pkgname etc
> # do install stuff
> ;;
> esac
> }
>
> I am kind of torn here... I like the idea of having a single function
> but the syntax is slightly more complex. Although the multi function
> version is already in use, that should not be a limiting factor - we
> should be striving for technical elegance rather than accepting the
> current situation.
>

The multi function way looks nicer to me.

>
> The second point I would like to bring up is based on the suggestion in
> FS#8187. In it I suggested having separate subdirectories where each
> sub-package is installed into. This would be a benefit because it would
> not require the clearing of the pkg directory after each sub-package
> install as in the current KDEmod implementation. I see this would be a
> definite help when bugfixing a PKGBUILD as you can easily browse the
> installed files. It would also mean that we could keep the repackage
> option working.
>
> This could be implemented with either method by setting the pkgdir
> variable before calling whichever package function is chosen. But it
> would require the forcing of the use of $pkgdir rather than
> $startdir/pkg as that would fail.
>


It seems like we already have a working patch for the kdemod /
multifunction way, though it apparently doesn't use separate subdir.
So maybe you could try to apply your idea on it?

$pkgdir will already be the recommended way for 3.2 (Dan commented it
that way in the man page at least ;) ).
With your suggestion, its usage would only be forced in the case of new
PKGBUILDs that use the split feature, and not to all existing PKGBUILDs,
so I think that's alright.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

"Dan McGee" 06-14-2008 08:13 PM

Splitting packages in makepkg
 
On Sat, Jun 14, 2008 at 2:22 PM, Xavier <shiningxc@gmail.com> wrote:
> Allan McRae wrote:
>>
>> I was going to wait until 3.2 was out the door to start implementing the
>> ability to split packages but there has been enough activity on the bug
>> tracker lately that I thought this discussion would be timely.
>>
>> There have been several proposals for building split packages with
>> makepkg. See:
>> http://bugs.archlinux.org/task/7144
>> http://bugs.archlinux.org/task/7982
>> http://bugs.archlinux.org/task/8187
>>
>> The question is how best to implement this. I can not see any other way
>> than having a "split" array listing the names of the split components,
>> so the need for this is almost a given.
>>
>> With input from the bug reports, I see two possible ways to implement
>> this (in the PKGBUILD):
>>
>> 1) The KDEMod style (FS#7982), where each package has its own install
>> function. e.g.
>>
>> base_install() {
>> # do install stuff
>> }
>>
>> gui_install() {
>> # override pkgname etc
>> # do install stuff
>> }
>>
>>
>> 2) A "package" function with a case statement. e.g.
>>
>> package() {
>> case "$1" in
>> "base" )
>> # do install stuff
>> ;;
>> "gui" )
>> # override pkgname etc
>> # do install stuff
>> ;;
>> esac
>> }
>>
>> I am kind of torn here... I like the idea of having a single function
>> but the syntax is slightly more complex. Although the multi function
>> version is already in use, that should not be a limiting factor - we
>> should be striving for technical elegance rather than accepting the
>> current situation.
>>
>
> The multi function way looks nicer to me.
>
>>
>> The second point I would like to bring up is based on the suggestion in
>> FS#8187. In it I suggested having separate subdirectories where each
>> sub-package is installed into. This would be a benefit because it would
>> not require the clearing of the pkg directory after each sub-package
>> install as in the current KDEmod implementation. I see this would be a
>> definite help when bugfixing a PKGBUILD as you can easily browse the
>> installed files. It would also mean that we could keep the repackage
>> option working.
>>
>> This could be implemented with either method by setting the pkgdir
>> variable before calling whichever package function is chosen. But it
>> would require the forcing of the use of $pkgdir rather than
>> $startdir/pkg as that would fail.
>>
>
>
> It seems like we already have a working patch for the kdemod /
> multifunction way, though it apparently doesn't use separate subdir.
> So maybe you could try to apply your idea on it?
>
> $pkgdir will already be the recommended way for 3.2 (Dan commented it
> that way in the man page at least ;) ).
> With your suggestion, its usage would only be forced in the case of new
> PKGBUILDs that use the split feature, and not to all existing PKGBUILDs,
> so I think that's alright.

Yeah, I definitely made those comments in the manpage that way on
purpose- this will allow us much greater flexibility in the future,
especially for things like building all packages in a tmpfs or
something. The only reason I can think you would still want to use a
$startdir variable is for something like VCS packages where you store
the most recent checkout somewhere for future use.

With that said, I've been pretty quiet on this whole split/multiple
packages issue simply because I'm not sure what is best, and I'm not
the one that would use it. A few thoughts of mine:
1. I've had this so-called fake_install() branch around for a while
locally, and I've always thought it was a decent idea:
http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=5e955fc9bd5 aa07263179a16b1cebeed9a43d25e
The naming of the fake_install() function could change, but what this
allows is for the build and install steps of packaging to be
seperated, and only the install step gets run under fakeroot. This was
the final step towards doing as little work in fakeroot as possible,
but I got cold feet on merging it because it would add some possible
complexity to PKGBUILDs. However, I think the idea is quite sound and
having a build() function and an install() function in a PKGBUILD
would not be too much clutter in my opinion.
2. The above mentioned patch would really play into what worked as far
as split packages. I think having the option of one or multiple build
functions, followed by multiple install functions, would be
beneficial. Here is what I envision, of course I haven't assessed the
practicality, and I can already tell I may be thinking too complex
after seeing a <30 line patch doing some sort of split.
options=('splitpkg')
(not sure yet where to stick the names/versions of other sub packages)
if build() is present, call build()
else if build_pkg1() is present, call that, then build_pkg2(), etc.
Each of these would get passed a unique srcdir?
call install_pkg1(), install_pkg2(), etc, each with their own unique
pkgdir (e.g. don't share a common pkg/ directory).

Blah. I don't know. But that patch from item #1 is more important to
me than the rest, so keep that in mind when I am looking at any split
package patches.

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Mark Constable 06-15-2008 05:19 AM

Splitting packages in makepkg
 
On 2008-06-15, Dan McGee wrote:
> The only reason I can think you would still want to use a
> $startdir variable is for something like VCS packages where you store
> the most recent checkout somewhere for future use.

Just on this particular point I have about 20Gb of VCS source
inside $SRCDEST and there is no way I want to have that much
persistent stuff spread out in 100s of separate source package
directories. Especially when one significant component is KDE
trunk which only requires a single svn up for what results in
a couple of dozen separate package builds. ATM I use a build
wrapper script that pulls *all* the VCS into $SRCDEST in a
single operation then the next step is to create the tarballs
also, obviously, in $SRCDEST then most of my PKGBUILDs just
refer to.. sources=($pkgname-$pkgver.tar.bz2).

If there could be something like a $vcsdir var, that defaults
to $startdir, in front of all the paths in the VCS management
sections of makepkg then that would be excellent.

--markc

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Allan McRae 06-15-2008 01:20 PM

Splitting packages in makepkg
 
Dan McGee wrote:
> <snip>
> 1. I've had this so-called fake_install() branch around for a while
> locally, and I've always thought it was a decent idea:
> http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=5e955fc9bd5 aa07263179a16b1cebeed9a43d25e
> The naming of the fake_install() function could change, but what this
> allows is for the build and install steps of packaging to be
> seperated, and only the install step gets run under fakeroot. This was
> the final step towards doing as little work in fakeroot as possible,
> but I got cold feet on merging it because it would add some possible
> complexity to PKGBUILDs. However, I think the idea is quite sound and
> having a build() function and an install() function in a PKGBUILD
> would not be too much clutter in my opinion.
>

This looks interesting. And it actually gives me some perspective on
which is the best way to implement package splitting. This would make
the standard non-split pkgbuild looked like:

build() {

}

package() {

}


So with a split package, the package part could be:

#1) KDEmod style

package_base() {
#do base install
}

package_gui() {
#override pkgname etc
# do gui install
}


#2) Modified KDEmod style

package() {
# do base install
}


package_gui() {
#override pkgname etc
# do gui install
}


#3) case statement way

package() {
case "$1" in
"base" )
# do install stuff
;;
"gui" )
# override pkgname etc
# do install stuff
;;
esac
}


Now think about how we keep backwards compatibility with old PKGBUILDs
that don't have a package function of any variety. Without split
packages, we have to test if the package() function is present to decide
whether or not the build() segment is run in fakeroot. This is
compatible with splitting methods #2 and #3 where there is a package
function but not with #1 which would require an additional check for the
definition of a "split" array. Option #2 also suffers from the problem
that there may not be a main part to package so it may not be obvious
what should be in the package() function. Thus, I think option #2 can
be excluded from here on.

Option #1 is essentially what the KDEmod team have done and would only
require an additional test for the "split" array to know what to use
fakeroot on. However, you end up with as many package functions as
there are sub-packages which itself makes the PKGBUILD less clear.

Option #3 is my personal favorite as you still only have two functions -
build and package. Admittedly the package function is slightly more
complex when building a split package but if you wanted it simple, you
would be using two PKGBUILDs instead of one. Still, I find it the
cleaner of the options but I may be fighting a losing campaign here
given option #1 is "in the wild"...

In the end, I think splitting packages is a nice feature but I doubt I
will use it frequently. So the decision should be weighted by those who
would. Now the KDEmod team chose option #1. My question is: Was that
because it was the best way or was it just because it worked? I think
it would be good to combine the whole split packages, multiple package
directories, minimal fake install ideas but I am still trying to decide
what the best way to do this is.



_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Xavier 06-16-2008 03:38 PM

Splitting packages in makepkg
 
On Sun, Jun 15, 2008 at 3:20 PM, Allan McRae <mcrae_allan@hotmail.com> wrote:
> So with a split package, the package part could be:
>
> #1) KDEmod style
>
> package_base() {
> #do base install
> }
>
> package_gui() {
> #override pkgname etc
> # do gui install
> }
>
>
> #2) Modified KDEmod style
>
> package() {
> # do base install
> }
>
>
> package_gui() {
> #override pkgname etc
> # do gui install
> }
>
>
> #3) case statement way
>
> package() {
> case "$1" in
> "base" )
> # do install stuff
> ;;
> "gui" )
> # override pkgname etc
> # do install stuff
> ;;
> esac
> }
>
>
> Now think about how we keep backwards compatibility with old PKGBUILDs
> that don't have a package function of any variety. Without split
> packages, we have to test if the package() function is present to decide
> whether or not the build() segment is run in fakeroot. This is
> compatible with splitting methods #2 and #3 where there is a package
> function but not with #1 which would require an additional check for the
> definition of a "split" array. Option #2 also suffers from the problem
> that there may not be a main part to package so it may not be obvious
> what should be in the package() function. Thus, I think option #2 can
> be excluded from here on.
>
> Option #1 is essentially what the KDEmod team have done and would only
> require an additional test for the "split" array to know what to use
> fakeroot on. However, you end up with as many package functions as
> there are sub-packages which itself makes the PKGBUILD less clear.
>
> Option #3 is my personal favorite as you still only have two functions -
> build and package. Admittedly the package function is slightly more
> complex when building a split package but if you wanted it simple, you
> would be using two PKGBUILDs instead of one. Still, I find it the
> cleaner of the options but I may be fighting a losing campaign here
> given option #1 is "in the wild"...
>
> In the end, I think splitting packages is a nice feature but I doubt I
> will use it frequently. So the decision should be weighted by those who
> would. Now the KDEmod team chose option #1. My question is: Was that
> because it was the best way or was it just because it worked? I think
> it would be good to combine the whole split packages, multiple package
> directories, minimal fake install ideas but I am still trying to decide
> what the best way to do this is.
>
>

What bothers me here is that the only question is asked directly to
the kdemod team. I am not sure they all follow this mailing list.
Maybe you should just ask them privately (have a look at the people
who contributed to that bug report).
But personally, I find that option #1 looks nicer ;)

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

"Aaron Griffin" 06-16-2008 03:56 PM

Splitting packages in makepkg
 
On Fri, Jun 13, 2008 at 11:24 AM, Sergej Pupykin <pupykin.s@gmail.com> wrote:
> Hi,
>
> I like following idea:
>
> PKGBUILD
> ------------------
> pkgname=foobar
> pkgver=1.0
> pkgrel=1
> subpackages=(dev doc)
>
> ....
>
> build() {
>
> .....
>
> make DESTDIR=$startdir/pkg install
> ...
> make DESTDIR=$startdir/pkg-dev install
> ...
> make DESTDIR=$startdir/pkg-doc install
> }
> ---------------
>
> According to subpackages array makepkg creates 3 dirs:
> - $startdir/pkg (as usually)
> - $startdir/pkg-dev
> - $startdir/pkg-doc
>
> PKGBUILDs build function install all stuff into them
>
> And then, makepkg creates 3 packages:
>
> $pkgname-...pkg.tar.gz
> $pkgname-dev-...pkg.tar.gz
> $pkgname-doc-...pkg.tar.gz

FTR I like this idea too. Just setup some way to use $pkgdir/foo/
instead of $pkgdir (that's what the subpackages=() array does in the
above example), and then the rest is free-form. It's the simplest IMO.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Jan Mette 06-16-2008 04:37 PM

Splitting packages in makepkg
 
Am Montag 16 Juni 2008 17:38:44 schrieb Xavier:
> On Sun, Jun 15, 2008 at 3:20 PM, Allan McRae <mcrae_allan@hotmail.com>
wrote:
> > So with a split package, the package part could be:
> >
> > #1) KDEmod style
> >
> > package_base() {
> > #do base install
> > }
> >
> > package_gui() {
> > #override pkgname etc
> > # do gui install
> > }
> >
> >
> > #2) Modified KDEmod style
> >
> > package() {
> > # do base install
> > }
> >
> >
> > package_gui() {
> > #override pkgname etc
> > # do gui install
> > }
> >
> >
> > #3) case statement way
> >
> > package() {
> > case "$1" in
> > "base" )
> > # do install stuff
> > ;;
> > "gui" )
> > # override pkgname etc
> > # do install stuff
> > ;;
> > esac
> > }
> >
> >
> > ... Now the KDEmod team chose option #1. My question is: Was that
> > because it was the best way or was it just because it worked? ...
> >
> >
>
> What bothers me here is that the only question is asked directly to
> the kdemod team. I am not sure they all follow this mailing list.
> Maybe you should just ask them privately (have a look at the people
> who contributed to that bug report).
> But personally, I find that option #1 looks nicer ;)
>
> _______________________________________________
> pacman-dev mailing list
> pacman-dev@archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev

Hi there,

i just registered at this ML - my first ML experience ever, so please be nice
to me :)

To answer Allans question about "our way" of building splitted packages...

When Dunkelstern and me realized that we cannot maintain over 200 splitted
packages with the standard arch makepkg, i sat down and created a first
prototype of a PKGBUILD for splitted packages. It was basically the same as
what you can see now in our PKGBUILDs, except the splitinstall array - i just
created multiple install functions, every one of these with an additional
array that holds the directories to "make install" in...
Dunkelstern took that idea, added the splitinstall array, created a patch for
makepkg, and after some testing and additional patching we had we basically
needed...

For us, it was (and still is) the best way to create splitted packages without
a lot of hassle and/or applying big patches to makepkg (which also have to be
maintained, we didnt expect that this will be a topic here) - and this
solution works good for us since we created this stuff, and has decreased
our workload a lot...

About the other 2 solutions Allan wrote about:

#2 looks almost the same like our stuff, except that is seems to implement
the "base package" stuff statically... We did not want that because with our
solution we have no limits and can split stuff like we want... (My english is
not that good, maybe i am sounding a bit too generic here)... Its like that:
If you already have the possibility to create a "base package", why do you
need to create an extra (static) package() function? Our solution already does
that by itself, and you can give the install functions any name you want...

#3 Seems to move more of the "splitting logic" into the PKGBUILD itself, which
isnt so nice imho... Also the case stuff decreases readability in my
opinion... With our solution we have just one additional for-loop and an array
of the directories to make install in, which is also very clear and
readable...

So, to come to an end here: I definitely see a some room for improvements
regarding our solution, but i also like the flexibility and freedom of it, as
you can define nearly everything as you like...

And in case you are asking yourself what could be improved:

- pkg/ gets deleted after the installation of every sub-package, so
re-packaging does not work
- the "-i" option to install packages directly after the build does not work
with splitted packages

(i am currently working on a patch for problem #2)

These are the only things that could be improved from my point of view...
We are using this stuff since a long time now, and i can say that we are very
happy with this solution :)

Greetings

Jan (funkyou)

PS: Again, sorry for my poor english




_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev


All times are GMT. The time now is 02:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.