Written by amiga_os the 8 May 08 at 21:56.
Category: Programming.
Related project:
Nothing/Others.
Status: Implemented
Rationale
NEW BRAINSTORM STYLE RATIONALE:
1) As a hobbyist developer, when I write little programs I want to distribute, it's unecessarily complicated, and takes learning an entire new skill base to create a Deb.
2) Making writing and distributing programs quick and easy is part of creating a good software ecosystem anyway (it saves time and money for a development company to use very quick tools that don't take much to train their workforce to use, making Ubuntu a more attractive platform to develop for)
3) Lots of fixes and workarounds for problems often involved having to install software from source. doing ./configure && make && make install means that software is installed outside of the apt package system, which causes numerous other problems. This is often unavoidable - I would love to only use apt for software installation, but particularly in the case of wifi drivers it's just impossible.
How do we make packaging easier, and make the package management system work with the ways that users have to use their systems already?
RATIONALE PART OF THE TEXT FROM THE OLD STYLE BRAINSTORM:
One of the major things that attracts people to Windows is the support Microsoft give developers - yes they charge extortionate amounts of money - but being able to do everything well, and simply, attracts developers, and helps them perpetuate bug #1.
Sun have made Java ubiquitous by making development a breeze with Java. Packaging is the single most irriating thing of developing for Linux. Particularly as there's lots of different package formats.
Totally agree. A lot of new users have no idea how to compile from sources. It's very important, because most packages in Ubuntu repositories are rather oldish.
zorkerz: From a technical standpoint, everything is there on the command line... what we need is someone to write a nice gui interface, where you can drag and drop things you want in the deb, graphically select dependencies, etc. etc.
The direction Glade is going in is really exciting. Anjuta is getting better - but it's still not a great ide. A good Deb gui builder would be the last chain in the process of code->package... then when Anjuta is (hopefully) as good as KDevelop, Gnome/Ubuntu will be an awesome platform to develop for.
Extending the functionality of the cli tools would be having the program detect possible dependencies based on #include statements in the code... but that's well beyond the scope of this idea for the moment...
Yeah, what we really kinda need is something that can watch what you do with your files (you drag them where they should end up in a finder like window).
The command line tools are sufficient. There is no wizard that will allow you to create a good package with a few clicks. For example, will it create your man page for you, deal with the file structure differences in upstream tarballs, etc.
Sorry, there's no way to "can" the abilities of a good DD.
Anyway, Linux programmers are already used to the command line.
Jhoger, are you a developer? Because I actually do some development work.. And if you don't do any development work, I doubt that you should really be talking on behalf of all developers of what's necessary or not to be honest...
If I have to dig around messing around with command line based packaging tools, I wont bother (I'll expect the distro's to package it themselves). The reason is, first I'll have to mess around with commands for deb's, then rpm's, then recipes, then etc..
And yes, I do know how to work bash, but if you think I will make packaging a free, open source program a priority, when it takes a lot of screwing around with commands, you are sadly mistaken, especially when I may need to do it again for other distro's anyway. I'd rather be coding!
Because apple has an easy to use packaging tool though, its heavily supported, and heavily used. So whilst you believe its unneccessary, it might be, but then don't expect developers to flock to linux to make packages when other OS's make this so easy to do..
Auzy, I absolutely agree... I don't understand the mindset of comments like the one jhoger gives.
All of these things are "unnecessary":
1) A graphical user environment... every was "possible" on BBCs technically - why did we ever bother with this gui idea? Totally unnecessary...
2) Distributions... all the bits needed to get a GNU/Linux system working exist out there on the web - why bother packaging it all up when people can go get it themselves?
3) Computers period... actually I could achieve all the productivity I needed to with a lot of paper, and a very complex filing system. And if I had enough abacus' then I'd be able to do most of the maths related research computers can - surely computers are unnecessary
In short - I see loads of ideas marked down because it's "possible" to get something done another way. But actually I don't want to do it *another* way - I want to do it an *easier* way. And that - incidentally - is why I switched from Gentoo to Ubuntu.
I just don't understand the hostility to simplification that seems to be rife in this community sometimes?
Please, I can program in C++, python, C# , Java, Pascal, I consider myself good to make applications, but making packages for Linux, is still very hard, I had to reuse someone else's ./configure setup in order to distribute a game as tarballs and I really can't find a good start point guide on how to make .debs
Either do this or create (good, easy to find, detailed) tutorials about how to make .debs for ubuntu, cause I really can't find any good info on this... I don't mind the command line, it might even be much better that way since I could make a new package with a single shell script whenever I have to. But I need a guide on how to do it... Debian packages guide seems to be full on path specification and no detail about how to make the packages themselves...
Well.. I wouldn't go as far to say I'm an awesome developer (I haven't programmed anything that has really gone mainstream, although my next program I hope will), but its good to say that there are other programmers who agree with me..
Sigh, I've never had my credentials demanded on Brainstorm, but since you asked...
Yes, Auzy, I am a professional software developer, full stop, since 1995. I guess I've been writing some kind of code since the '85 (BASIC on my TRS-80). I have my Bachelor's in Computer Science, and I have authored one package that is part of Debian (I packaged gopchop). Having created a Debian package that is shipping does qualify me to comment.
I program professionally in C, Perl, C++, 80x86 assembly. People pay me money to do this.
I don't use GUI IDEs, though they are available. I use a shell prompt, makefiles and Vim. I find GUIs less productive than automating things properly with a makefile, good knowledge of a powerful text editor, and scripts.
jhoger... nobody is doubting your credentials... great for you.
The issue was the way you spoke for ***all*** developers in saying that it would be totally unecessary for them to want a simpler way to package their programs for Ubuntu.
Then a lot of people replied by giving their credentials to show they were programmers, and that you weren't speaking for them.
I think it's really great that you're in our community, and you don't need this feature, I'm glad that we have people who can handle creating packages with the current tools - and who are so adept at it, that they don't need (or even want) the process simplified. However... many of the rest of us in the community, who program code - maybe professionally, maybe as a hobby in our spare time - would value this feature.
And I also personally think that one of the major battlegrounds between development platforms is the simplicity of being able to code, package and distribute software. It saves companies time and money if they have easy, simple tools to do those things quicker - and so when it comes to a choice between different platforms, it makes *economic sense* to choose a platform that has easy ides/libraries/distribution tools.
You may be a programmer - but have you ever had to *manage* the resources of a company in a cut-throat market? If you have, then surely you understand that taking the "hard-core" route is simply not viable for the commercial software outfit. For that reason, I think this is a feature that we would all want to see, whether or not we would personally use it. It makes Ubuntu a more attractive platform for developers.
I believe that open source software is superior to proprietary software, because features like these can be put together more quickly, more efficiently and with better quality when people collaborate around an open platform.
However, the problem with the open source community is that many people treat "ease of use" as though it were not a feature, but rather an annoyance. And because of that "ease of use" features often get sidelined.
The reason I use Ubuntu, is, I felt it was the first distribution that really, properly, embraced "ease of use" as though it was something we should be proud of. And I agree. It is.
Example: I could write all that wonderful Glade XML myself. Or I could use a gui to build it. Or I could use the gui to get started, then tweak it if I needed something more complicated.
I'm not a developer by any means, but I have done some .deb packaging and its really not that hard. If your program compiles with a ./configure and a make, its really a 5 min (tops) procedure to make a deb of it. dh_make, edit a few text files, debuild.
I'm not saying it would be a bad idea to have a gui tool to do this, just that its not a terribly complicated process to do without it, and once its done theres no real effort involved in updating the deb as the program updates (just a couple lines in the changelog).
I'm trying to start an Ubuntu project. I have the programmers under me, we just don't know how to build the .deb files. This would be extremely useful.
* Your makefile is broken, here are some suggestions:
* You have no dependencies, is that correct?
I once tried to develop such a software, but I couldn't figure out how to make a .deb package with the instructions written in the Ubuntu wiki (or almost anywhere else).
This whole thread is more "we should do everything like Windows does" but applied to developers.
Command line tools are the mainstay of serious programmers *because* they make you more productive in the long run. What is the figure we learn in software engineering... like 65% of a program's lifecycle is the maintenance phase. That means that the effort necessary up front is less important in terms of cost than how the way you did things up front impacts costs in the maintenance phase.
If I need to make a similar change in 50 spots should I have to go through a bunch of GUI menus to do it, or worse, have to regenerate everything using a wizard that I cannot script? The command line Way means you can use your toolbox of text processing tools to do Big Things, Efficiently.
If you want to churn out crap VB code using crap VB programmers, this idea is just the kind of thing to do.
BTW, amiga_os, you're still taking the opportunity to impugn my credibility. What else can I say? I have managed programmers. I've done both Linux and Windows development. I just finished work on my MBA so I know a bit about competing in the marketplace.
All that, and I think going down the VB path is still a poor idea.
But hey, whatever. Every generation of programmers has to bang their head up against the same wall and reinvent everything for themselves.
"Well.. I wouldn't go as far to say I'm an awesome developer (I haven't programmed anything that has really gone mainstream, although my next program I hope will), but its good to say that there are other programmers who agree with me.."
I didn't really intend to say I am awesome at programming, but I consider myself good at that, at least I got more practice than the average.
I consider this brainstorm post a blessing, I have finally found good links to instructions on how to make packages... time to learn.
jhoger: Something to consider is that the availability of GUI tools for .deb creation, will not really hinder the existence of the command line tools, most likely the GUI will need the command line tools anyways. So developers will be free to use the command line tools if they want.
So, geany and code::blocks exist, but I still use make to compile since I think that's more effective a tool for these things, that's the nice thing about Linux, that you get to choose, periodically.
Someone really is not getting the idea that an *easy* way of things is the way to go.
Like, this is why I'm on Ubuntu and not Gentoo or whatever to begin with. That's also why a ton of other people are. The same concept can be applied to people who'd like to make software, *easy* is good.
... yet no, everything should be complicated, "powerful", and don't forget the rtfm.
Its possible I would amiga_os.. I have designed a program called menutogo, so I could see the same program also being able to generate a menutogo file too ;)
I would like to add just a bit of input as both an Ubuntu and Debian developer (maintain quite a few packages in Debian and a member of both the MOTU and MOTU Council in Ubuntu).
checkinstall was a program that was created years ago to make distribution packaging easier. If you have ever given it a shot you would see just how easy it is to create a package. BUT...they are junk packages and I would recommend any and everyone from installing packages created with checkinstall. It has the potential to create a dependency hell for those that use it.
I have no problem with a gui front end to packaging, however I just do not see how efficient and good it could be. When doing Debian packaging, the person doing the packaging needs to understand policies that are put into place. The policies deal with a certain way changelogs, compat, control, dirs, docs, rules, watch, and more files should be setup. OK, so this sounds easy right? You are still going to have to do manual editing no matter what.
Each application is created differently upstream, that is what would make this type of project a true pain in the arse to complete successfully (my opinion at this time). You are going to have to know what the package dependencies are (using CMake and having properly formatted CMakeLists.txt files though could make this part a bit easier), manually setup the copyright file because who knows how each file is setup. I have yet to come across a package where each source file had the same formatted headers, so when I do 'licensecheck --copyright *' I get all kinds of goofy info back.
I just don't see how a GUI is going to help this process. Seriously, Debian based packaging breaks down to something like this:
> download your upstream application tarball
> extract the tarball
> ensure the extracted directory name meets policy (appname-version)
> cd into directory
> dh_install -e your@email.com -f ../app.tar.gz
> answer the question asked (single binary, library, cdbs, and such)
> cd debian/
> rm *.ex *.EX
then the rest you could simply edit with a gui text editor (gEdit, KWrite, Kate, whatever)
the building part is seriously a couple of commands
> cd ../
> debuild -S -sa
> run it through pbuilder (or run it through a chroot and test it out prior to pbuilding it)
----
I have tried scripting some of the processes involved, but because the upstream developers package their application differently (configure, cmake, install.sh, setup.py, whatever), it can be tricky.
In order for something like this to really work, all application developers would have to agree to a specification in which every application created would have to be packaged the same. Have them create their own copyright files that would easily be absorbed by a script into debian/copyright. The problem with this is getting every developer in the world to agree to this, and we know this isn't going to happen, unless the god of all packaging managers is created. Developers are pretty much set in their way and have certain ways they do things. Telling someone who programs for fun to do it this way only more than likely isn't going to work. I prefer to use CMake for my applications, but I guarantee non-KDE developers are going to use it. sure I could use the old school configure & make process, but like some of you already mentioned, creating these makefiles can be a pain in the arse.
end my 2 cents...thanks everyone, and I don't mean to get anyones hopes down. If you think you can take on such a project, then go for it, but understand all of the processes involved with every step of packaging, both upstream and downstream. That is a lot of understanding and programming :)
I just tried out the first one yesterday, and it worked. I didn't have to spend hours reading manuals or press random keys like a monkey who has no idea what he's doing in the terminal. So, my apologies to all the offended parties, but it's +1 more programs on Ubuntu now :)
let's not forget that jhoger and any other hardcore old school developer is in his best right to disagree with whatever opinion.
If their opinion ends up being less voted than the alternative (assuming only two alternatives are being seriously considered), then someone might pick it up and
I agree with some of jhoger's points, but since some (most?) of the steps in packaging are alredy automatized by scripts, I don't see why a GUI to call these scripts isn't a win-win situation. At the end of the day, if one prefers the CLI (as I probably will) one will continue to use and improve that medium.
> I just tried out the first one yesterday, and it worked. I didn't have to spend hours reading manuals or press random keys like a monkey who has no idea what he's doing in the terminal. So, my apologies to all the offended parties, but it's +1 more programs on Ubuntu now :)
No offense taken over here. In all honesty, I couldn't give a damn about the relative popularity of an idea on Brainstorm - what I want is a GUI that makes packaging feel really easy. The problem with CLI I've always felt is that there's only limited amount of information on the screen for the noob. With a graphical interface, I can see 15 options immediately, that I recognise need to be dealt with if I'm going to package something.
Of course, the fact that there's a program been written to do this simply illustrates that the *idea* that there should be a program to do this is felt strongly enough by someone, somewhere, to have actually started writing it.
To all of you hardcore guys, who don't like the idea of noob's packaging stuff, can I just say:
1) Thanks for your contributions to FOSS, without hardcore coders like you it wouldn't be here.
2) Please be patient with us, we do have something to offer.
3) My username - Amiga OS - is in respect of the Amiga, which was so awesome for the very reason that in it's day it brought the ability to program, and run whatever I wrote on my mates Amiga, down to the level of noob's like me. For that reason I subsequently fell in love with FOSS, and subsequently became (very very modestly) involved in contributing to projects.
This idea is for all of us who long to write our own programs, who long to help, and who think that having a really streamlined, phenomenally simple and slick process that supports the hobbyist programmer from "initial idea" to "user installation" would be a phenomenally *good* thing for Ubuntu. Not just information - but also simplicity and opportunity - empowers people.
This idea is simply part of a software stack I long to see where anyone can release little games and projects we've made for Ubuntu really really easily.
> binary packages taht are precompiled should be able to be created as easy as that shoudln't they?
I absolutely agree - why *shouldn't* it be ueber easy?
And - in my ideal packaging program - it would use your c/c++ header files or Python #include statements to draw up a pretty intelligent and clever list of what packages your package is likely gonna need to depend on.
I can then test everything using a chroot environment, and most of my "packaging time" is spent making sure the package installs all the proper dependencies, and not fiddling around with all the technical stuff that can be automated.
I don't see this as being a 'professional developers' tool. Rather a 'Ubuntu has a 2 year old version of MESS that won't actually run in Ubuntu. I may not be a developer perhaps I can manage to get the latest sdlmess packaged with the official Ubuntu Packager GUI' tool.
This is not for efficiency. This is not for optimization. This is simple for an amateur to contribute a package to the Ubuntu OS.
I think the resulting amateur efforts should be marked as such and reviewed at some point by a professional. And not necessarily added to official repositories (without some sort of flag).
This could be a stepping stone. An amateur makes a few packages, gets some feed back, improves it, eventually one of his packages is judged appropriate for the officially repository. This would be encouraging and the person might consider becoming a real developer.
Its been done. But for the sake of keeping Ubuntu a quality distro, Canonical should 'officialize' a package and procedure even if it doesn't become part of the paid support.
Ya know, there's a rumor going around that Linux is not just for developers anymore.
Absolutely nobody is suggesting that the standards for inclusion in the distro should be reduced.
And - I personally don't think that simpicity, ease of use, and making things "nicer" is something that doesn't attract real, serious, developers.
OF COURSE - people who are already serious developers on Linux platforms disagree here - BECAUSE - the development platforms for Linux aren't easy to use (in comparison to Microsoft's tools), and so coders who like doing things the hard core way are the ones attracted to Linux.
Simply in marketing terms, if the learning curve for designing, developing and packaging programs for Ubuntu is made shallower - then more companies will invest in writing programs for Ubuntu - or at least as the barrier for porting applications is lowered, more companies will consider it. Since Ubuntu and Linux generally - as an OS - is a platform that relies on a software market that builds upon it, anything to encourage that software market is a good thing.
This is something that Microsoft understands really well, and that's why things like DirectX are really easy to code with, and why they've tried to make all their development tools as easy to use as possible.
I just don't understand why we find this so hard to "get" in our community.