Arch Linux

OH! I forgot sqlite! Such a shame! Yes it includes that too. :)

Well, those didn't exist when I made the package. And as they are only used in the netsurf package, I included they in the same package (following the "avoid to split packages" philosophy). The sqlite tarball is used to workaround a building bug. I found no other way to do that.

About adding the package, it had a good amount of votes when I upgraded the PKGBUILD, so I thought moving it to [community] would be a good idea. Not only because of votes, but because a light browser (nowadays netsurf is more used than dillo in those scenarios by what I can see) can be useful in low end machines, and because it can be useful for webdesigners to test websites in one more environment.

But I have no problem to move it back to unsupported if you fell this should not be in community. I just moved it in good intention.

Build scripts shouldnt look like that. The dependencies should be seperate packages. Period. Thats unless they can be statically built.
Its not a matter of moving it back to unsupported or not. Also i am not questioning your intentions. I am sure you meant well.

Currently, they are statically built by this package. I just checked, and what could be a problem here is that the development files (headers, static libs, pkgconfig files) are included in the package. Do you think we should remove that?

I think it would be better to stay with only one package for netsurf if possible. I think those libs will hardly ever be used by another project. (I don't know why the netsurf developers had chosen to split their codebase like that.)

I think the big problem here is the sqlite bundling.
I wouldn't really expect you to package netsurf specific libraries separately.

Well, sqlite is not being built at all. I'm only using the lemon tool that comes in the sqlite tarball to regenerate a parser's code during the building process.

I could get only lemon directly from the sqlite repository, but I thought the tarball would be better because it can be included in the sources array and because its md5sum can be checked.

You can still put it in the sources and get it directly from the sqlite repo, etc.

That'll get you the same revision every time:
http://www.sqlite.org/cvstrac/getfile?f=sqlite/tool/lemon.c&v=1.69

Prefix it with 'lemon.c::' in the sources array.

Good idea Loui :) I will modify the PKGBUILD tomorrow to do this way.
Any issues/suggestions left?

"Currently, they are statically built by this package"

Statically built means that the netsurf source ($pkgname-$pkgver) would include all those libs and you wouldnt have to download them in order to build netsurf. Which clearly isnt the case here.

"I think those libs will hardly ever be used by another project"

That is no excuse not to build them seperately. See for example libmcs & libmowgli with audacious. Packaging in Linux works that way.

"Any issues/suggestions left?"

IMO if you arent willing to build a proper package it would be better to move it back to unsupported and suggest to the one who picks it up to make the changes himself.
But im not gonna be using this application anyway.

Well sorry for all this arguing Greg, I really took a time to understand your point.

I will wait until tomorrow to see if anyone disagrees with splitting the packages, then split them.

I would only want to clarify that the reason for merging the packages was not only because no other packages use them currently, but because I was concerned with the problems we had last year about the *number* of packages in community growing and slowing down the community backend (that required some repository cleanup and new rules for packages entering community). I don't know how much this is a problem right now, but I just took some advice with Hugo and he said that should not be a major concern, so let's go for it if nobody has any objections.

Please tell if any issues/suggestions/concerns are left. I would prefer to do all in one go for pkgrel=2.

Arguing ( http://www.merriam-webster.com/dictionary/arguing ) tends to bring the best results most of the time. :)
Sorry for not being clear about what the issue was, but i amazed to discover a package like that .Thought the problem was obvious.