Jump to content

Home-grown software


Recommended Posts

Hi, this is kind of a speculative question, but I'm curious what the process is for getting software included into the standard Mandriva repositories so that it's available via urpmi.

 

Let's say I write a GPL'd program, and want to distribute it. Let's say it's written in C++/Qt so it's native and free. I could either:

- Distribute a source tarball myself, and give instructions for how to compile and install it. (Cross-platform but awkward for users)

- Build an rpm myself (once I figure out how) and distribute that myself (Mandriva-only but less awkward to install)

- Somehow persuade someone that it's good enough to get included into the urpmi libraries, so that all users have to do is use urpmi or the add software gui (Mandriva-only but super-duper easy to find and install).

 

Of course the rpm options don't solve anything for other Linux users, not to mention Windows / Mac users, but it would be extremely cool to be available in urpmi. Any ideas what the request / approval / build procedures are like, is it something that mere mortals can achieve?

 

At the moment the software I'm talking about is only written in java, which simplifies the compilation enormously (compile once on Mandriva and just deliver jar file to linux / mac / windows / unix) but isn't really suited to being rpm'd (requires jre which may or may not have been installed via rpm). So I'm wondering what the score would be for a C++/Qt rewrite...

Link to comment
Share on other sites

I've also been looking at this. I've built both debs and rpms for myself, but I have never taken the time to make the rpms compliant with Mandriva policy, or have them submitted and approved.

 

You can find the info you need here:

 

Howto/Submitter

 

Howto/Maintainer

 

Howto/RPM

 

Please note the Rpmsetup.sh in this section:

 

Howto/RPM#Create_.rpmmacros_file

Link to comment
Share on other sites

Great, thanks for those links, they're really useful.

One thing that caught my eye: "New packages, of course, are welcome, but you'll have to find a maintainer interested in adopting it."

Which raises an interesting point - I've only got a single machine with 32-bit i586 architecture, so there's no way I could make all the rpms myself anyway. So I would need someone at Mandriva to make the other versions for me, it's just not clear how to do that or what the criteria for inclusion are...

Edited by neddie
Link to comment
Share on other sites

Which raises an interesting point - I've only got a single machine with 32-bit i586 architecture, so there's no way I could make all the rpms myself anyway. So I would need someone at Mandriva to make the other versions for me, it's just not clear how to do that or what the criteria for inclusion are...

That is one of the many obstacles that I did not try to overcome, or have the time to try to work out.

I've noticed that some of the links are dead for info pertaining to this. So instead of using an old email address for a question about this, that may go unseen. I would suggest an email to adamw at the address in his sig for more info. I'm sure that he would help you... or lead you to the info you seek.

Link to comment
Share on other sites

We (maintainers) don't build the binary RPMs manually. We work on the .spec files and the sources, then commit those to an SVN repository (which you can browse at http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/ ), then we submit a build to the official Mandriva buildsystem, which results in the buildbot checking the .spec and sources out of SVN, creating a .src.rpm, and rebuilding that .src.rpm on all the officially supported architectures (just i586 and x86_64 for now) on the Mandriva build cluster. Then the resulting packages are automatically uploaded to the mirrors. You can spy on the process here:

 

http://kenobi.mandriva.com/bs/

 

so yes, the short answer is, you need to find a Mandriva maintainer (either a staff member or a contributor) willing to package your app. If it's a simple app and you're willing to drop me an email when you release a new version (so I don't have to keep checking), that can be me. :) Just send me the app, a link to the app's home page, whatever.

 

There is an 'official' procedure by which you build a .src.rpm and upload it to ftp.mandriva.com/incoming . Theoretically, at this point, a Mandriva packager will look at it and either accept or reject it.

 

In practice, we're all way too busy and no-one ever does. There's packages that have been sitting in that directory for years. It's far better to find a packager yourself, or post to the cooker mailing list, or something.

Link to comment
Share on other sites

Thanks Adam, that's a bunch of useful info, thank you! :D

 

So if I understand it right, it would indeed be possible to get a C++/Qt application included in the Mdv repositories (although sadly all other linux distributions / windows / mac users would have to compile it from source themselves), if you'd be kind enough to do the maintaining for me. I assume I'd have to get it at least as far as an rpm before submitting it.

 

As to the java, I find that curious that it's so complicated / messy. Is it messy because you need to do the compilation yourselves and therefore need the JDK tools and supporting class libraries etc? My naive impression would be that you could take a compiled jar file, put it inside an rpm with a description and stuff but no dependencies, and then done. The user would then have to make sure they have their own jre (from wherever) and call it themselves from the command line, but at least the download and install of the jar file would be automatically handled by urpmi. No compilation, no makefile, no dependencies, no install scripts, no native code or fancy stuff, just a single jar file installed to /usr/lib/nameofapp, kind of like an rpm which just contains resource images or help files - they don't have source rpms or build procedures either I guess. Ok, so it would be nice to have a launch script in /usr/bin to check if a "java" executable is available and complain if not, but I guess that's pretty easy, no?

Link to comment
Share on other sites

We don't do it like that. By policy, our package must build the stuff from the source code, it can't just be a pre-compiled .jar thrown in a .src.rpm wrapper.

 

The Java stuff in MDV is messy mainly for historical reasons. We used to never package Java stuff ourselves, we used an external repository called JPackage. Since it's become feasible to build quite a lot of Java stuff with a fully free software toolchain (i.e. the proprietary Sun Java is no longer needed), we've started having Java packages in our official free repositories, but we still keep them in sync with JPackage, so they're rather different from standard Mandriva spec files. Add to this the fact that free Java is inherently messy and we package (at my last count) about six competing implementations, and yeah, I am really not very well up on it. There are a couple of guys - Pascal Terjan and David Walluck - who really understand the Java stuff, if I wanted a Java app packaged, I would just ask them to do it.

 

neddie: yes, it would be possible to get it in the repos, and no, you don't need to figure out how to build an RPM yourself. My general philosophy here is division of labour. I do not have a sodding clue how to write code, and wouldn't try. On the other hand, I - and the other Mandriva packagers, staff or volunteers - can build a proper working package compliant with all Mandriva policies pretty much in my sleep. You, I expect, can't - through no fault of your own, you just don't have the experience (as I don't with coding). Therefore it seems to me a fairly reasonable plan that you stick to your area of expertise (coding) and I stick to mine (packaging). So just throw me a tarball (and if you're feeling nice, a list of build dependencies - that's always good) and I'll do the package.

 

I think this is a fairly good philosophy in general. 95% of the time when you go to an app's website and it has an RPM or .deb package that the author built himself, it's rubbish in packaging terms, just because a good coder is not the same thing as a good packager. Personally I reckon it's a far better idea for the developers to simply provide the source code and rely on distributors to do the packaging. It's easy enough to have a download page which says 'A pre-packaged version of the application is available for your distribution - refer to http://foobar for instructions on installing it'.

Link to comment
Share on other sites

The Java stuff in MDV is messy mainly for historical reasons. We used to never package Java stuff ourselves, we used an external repository called JPackage. Since it's become feasible to build quite a lot of Java stuff with a fully free software toolchain (i.e. the proprietary Sun Java is no longer needed), we've started having Java packages in our official free repositories, but we still keep them in sync with JPackage, so they're rather different from standard Mandriva spec files.
Using these free Java implementations had\has two consequences: not working packages and\or ridiculous dependencies. Sun Java is now in the non-free repo. Use it. Save the extra work for yourselves and the frustration to your users.
Link to comment
Share on other sites

We don't do it like that. By policy, our package must build the stuff from the source code, it can't just be a pre-compiled .jar thrown in a .src.rpm wrapper.
I guess that makes sense, that prevents me from compiling malicious code and packaging it with benign source... But yes it does make the packaging then more tricky. This particular java app uses Sun's Swing classes for the gui (javax.swing.) and as far as I know the free reimplementations of the jdk don't have these classes available. And to make it even worse, in order to build all the classes, you need Sun's java3d package installed (from blackdown.org) - you don't need them to run the code (the 3d stuff is an optional feature) but you do need it if you want to compile all the classes because they refer to the java3d classes.

 

So it looks like the only option for the java version is to learn how to make the rpm myself, offer the rpm for download myself, and hope that people trust my compilation (like they trust my downloadable jar already). But then that doesn't really provide any advantages over the downloadable jar.

 

OK, so if I were to do a rewrite in C++/Qt, that would make the build process easier and thanks again for offering to do the maintaining. It'll certainly be a while (probably a long while!) before anything is ready, but I'll remember your offer! ;) I'm just a bit worried that for all other distributions there might not be such a positive response, so I'd spend ages writing an app which is then only available on Mandriva (or for those brave enough to compile themselves). I'd have to beg help from each of the dozens of popular distributions in turn, right? At least the java version works on all those systems already, it's just not as integrated into the repositories as the native version could be. And of course that's not to mention trying to produce binaries for Mac systems and Windows systems, but that's another story...

Link to comment
Share on other sites

What's the deal with Sun's java being non-free or free or open source or partially open source? Is the plan that the whole jdk and jre will one day be completely open source, and then the packaging and rpm'ing of java applications will then be completely straightforward? Or is that likely to take years?

Link to comment
Share on other sites

a lot of it is now truly open source. We have IcedTea in 2008, which is basically the open source bits of Sun Java with the bits that are missing replaced from the other open source Java projects. I don't know the exact timeline for the rest of Sun Java getting properly open sourced, I'd guess it'll be for 2008.1 or 2009.0.

Link to comment
Share on other sites

OK, thanks again Adam.

Maybe in that case it would be quicker to wait for IcedTea to become fully functional to run the java version, rather than to wait until I've rewritten this app in C++/Qt ! But then again it's turning into an interesting exercise anyway...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...