Hi Phil! Am Montag, den 20.12.2010, 22:56 +0000 schrieb Phil Bull:
I'm not really sure what this will take. Ideally, an Anjuta user would be able to click "Build as XXX package" button or something and have most of the packaging done for them. Would this require some assumptions on the project type from the start? (i.e. would they have to choose an "XXX package" project type first?)
It would definitly require some assumptions. I will give some examples: * project uses autotools * project doesn't require any non-pkg-config libraries * project is an application (e.g. no library, no multiple packages, no -doc package) I guess we can mostly make these assumptions. We could try to deal with doc packages later.
There's no need to fully implement the Quickly interface - only the packaging stuff is needed really.
The problem I see here is that quickly doesn't use any build system (or well, it is kind of a build system but scripted and as such impossible to parse/import into and IDe.
Can anyone outline broadly what would be needed to get something like this working? For example, people at the hackfest mentioned a need to convert between different package naming standards in distros (for dependencies etc.). Then would you need some sort of parser (or settings dialog) that handles deps? And maybe package templates, or packaging format description files?
OK, I can try to outline a but a of a vision here about how things could work: * The user would be presented a dialog where he can set certain "soft" options on the project: - Project description - Project version - <more metadata> * Anjuta would than try to generate files need for packages: - Check with packages provide the .pc files of the libraries we need (can be done directly with pkg-config names with rpm/yum, some magic is needed on Ubuntu, would be nice if we had a working PackageKit there). - More difficult is to find the runtime dependencies since anjuta does only care about building usually. I don't know a reliable way to come from -dev package to the normal package. - Combine metadata and packages into the appropriate files (spec file, debian/) For the spec-file I kind of think it can be done and will have a look into it when I have some spare time. For deb the problem is that dpkg is usually used to generate a lot of files in the debian directory while we probably only care about the changelog and the control file. Those are difficult to handle though because dpkg is very piky on the format and it is not really machine readable. But maybe people that have more experience with debian packaging could help out here. Last step would be to start the package generation process. That is probably straigh-forward by just executing rpm or dpkg commands. So far, so good. Things get worse when we want to support cross-packaging, e.g. build a debian package on Fedora. It is much harder to use the packaging system to detect dependencies this way. This is where the OSBS could dive in but it has to be investigated. Regards, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part