On 15 November 2012 15:18, Andrey Rahmatullin <w...@wrar.name> wrote:
> Bottom line: if you want to get a good package, it's not always possible > to fully automate that, especially in cases of complex (and proprietary) > software like that you mentioned, and so a GUI wizard can't do everything > needed. > I absolutely agree, but as I see it, I'm not trying to automate the process. I'm trying to make it easier for the user to manually intervene in the packaging. The wizards are just one part of that. Packaging at the moment involves an array of different data files, specialist syntax, and command line tools. There's a lot of detail which is hard to learn and remember. For example: - uscan puts upstream tarballs into ../, but svn-buildpackage expects them in ../tarballs/ - dh_make is something for the user to run, whereas dh_install is something to be run automatically by the build system. - When you make a new patch, you have to 'quilt add' any files you want to modify before you can modify them. It's easy, and annoying, to forget that. (I know about 'quilt edit', but for other reasons my $EDITOR is set to an in-terminal editor, which isn't what I prefer for modifying large code files) - To work on patches, you have the debian/ directory in amongst the upstream codebase. But having the rest of the codebase there clutters up information from the version control system. So I often end up with two copies of the packaging, and copying debian/patches/ between them. - You call pbuilder with a .dsc file, but dput with a .changes file. - In the <pkg>.install list, a line with a single entry works quite differently from a line with two entries To be clear, I'm not asking for solutions or workarounds to these individual issues. I'm sure there are good reasons things work the way they do - but being relatively new to this, the array of not-quite-connected tools is daunting. I think the advantage of a GUI is that it presents your options, rather than requiring you to already know them. If you realise you need to change some of upstream's code to make the package work... hey, that pane says 'patches', that sounds like the thing. If there are some examples, you can see the binary package target has an entry called 'examples'. Specifically, some of the things I have in mind: - Integration with quilt for patches. If you try to edit a source file from the GUI, you're prompted to create a patch. - A joined-up view of the intended binary packages. At present, the details of a binary package are spread out over part of the control file, and the foo.install, .docs, .examples, etc. files. - Editing copyright info without having to get the file syntax just right, look up license short names, and so on. Just enter a glob and select the license from a dropdown. - Wizards for specific things like watch files or DEP-8 tests. The key to this is that GUI wizards have a much lower barrier of entry than new command line tools - no flags to remember. - A build menu where you can select source package, local build, pbuilder or PPA, and it will take care of any preparation needed for that. Whew, that's more than I meant to write. Thanks to anyone who's read this far - I hope I've managed to give a clearer picture of what my idea involves. Thanks, Thomas
