Am I the only one who sees the word "run" bolded? Or the link to the exact page with building instructions: "Instructions on compiling Sigil can be found on the BuildingFromSource wiki page."? It's the very next sentence after the list of libraries required to run Sigil. "libqt4-dev" is not required to run Sigil, but is required to build it. This would be the reason why it's not listed in the libraries required for running, but is listed in the libraries required for building.

Also, none of this text is in the INSTALL.txt file included in the source package you downloaded. That file only has the text from the BuildingFromSource page, since with the source package you'll be... building from source.

I honestly don't know how to make all of this more explicit for new users. I guess I'll have to try.

I honestly don't know how to make all of this more explicit for new users. I guess I'll have to try.

It's very clear from the README.txt and INSTALL.txt. If someone can't be bothered to review the files included in the zip file I don't know that there's anything that can be done to help that person short of binary packages.

You are free to do so, but this is rather unnecessary. Making a deb with checkinstall is useful when the install process puts many different files in many different places. Sigil's install process installs only one file: "sigil", which is placed in /usr/local/bin (this path can be changed, see the build instructions for more info).

The advantage is that of using the distribution's package system, which means you have a centralized database of installed packages, a centralized way of installing and uninstalling, of querying the version installed, etc.

At the moment you may have a single file (which I just copy in ~/bin, by the way), but later on you may want to install man pages, samples, templates, HTML help pages, command-line helper apps... It's a good practice to use "sudo checkinstall" rather than "sudo make install".

The advantage is that of using the distribution's package system, which means you have a centralized database of installed packages, a centralized way of installing and uninstalling, of querying the version installed, etc.

At the moment you may have a single file (which I just copy in ~/bin, by the way), but later on you may want to install man pages, samples, templates, HTML help pages, command-line helper apps... It's a good practice to use "sudo checkinstall" rather than "sudo make install".

Oh I agree, it's good practice. But currently for Sigil I think there is little point. Of course, no harm would come from using it.

Although in general I have heard that checkinstall instills one very bad practice in users: the distribution of packages created with it, when those packages are meant for the machine where it was first run. People think that the created package is just like those from the repos, and this creates problems.

1- a rtf file called "Compilation" which is the exact text log of the first two commands. You may note one explicit error at 19%, which seems to have no importance, but who knows?
2- a rtf file called "checkinstall" which is the exact text log of the checkinstall command I used. Please note that I included the four needed dependencies to run the program (but not the last one, libqt4-dev, which is not needed afaik)
3- a deb package which should run fine on 32 bits systems for distros using debs like Debian, all Ubuntus, Mint...

The checkinstall program is also able to produce rpm or slack packages but I have not enough experience with these distros to dare produce it.

Thank you for trying to help roger64, but for security and quality assurance reasons I will not distribute binaries from random people on the internet.

And checkinstall is not meant to be used to produce packages that are to be installed on computers other than the one used to make the package. The deb and rpm packages you normally install from your distribution's package repository are created with a lot more care and precision. It is not an easy or simple process by any means. For more information on creating distributable debs, take a look here. Just creating debs alone is rather complicated. Rpms AFAIK have their own complex procedures.

Those things aside, just providing deb and rpm packages would not be fair to the other Linux users whose distributions do not use them. There are many other package types. Providing some and not others would still leave a lot of people unhappy, and I just don't have the resources or the time to make a dozen different package types.

As I've noted in (several) previous posts, many (major) software projects provide only source archives for Linux. From GCC, GIMP, Inkscape etc. These people have met the same hurdles I have met, and have a lot more manpower available. Their solution is to provide sources, which users can then compile themselves or leave it to the package maintainers to handle for them.

Sigil will do so as well. This is final.

This decision is not the product of laziness, lack of skill or malice. Simply a consequence of Sigil being a one-man-project, and a hobby project at that. That being said, many larger projects still provide only source archives for Linux. I've said this too many times now, and I'm starting to sound like a broken record.

I hope I've made my point clear. If I haven't, well... I gave it my best shot.

I hope I've made my point clear. If I haven't, well... I gave it my best shot.

I would suggest that those who really must have a binary package for whatever reason might get involved with the community of their preferred distribution and see if they can't get Sigil considered for addition to that distro's repositories or whatever.

For the sake of objectivity and for the information of our readers, I need to correct a misconception about the technical value of checkinstall built deb packages stemming from our previous posts. This will be my last shot.

Quote:

Originally Posted by Valloric

.../...
And checkinstall is not meant to be used to produce packages that are to be installed on computers other than the one used to make the package. The deb and rpm packages you normally install from your distribution's package repository are created with a lot more care and precision. It is not an easy or simple process by any means. For more information on creating distributable debs, take a look here. Just creating debs alone is rather complicated. Rpms AFAIK have their own complex procedures.
.../...

To write that "checkinstall is not meant to be used to produce packages that are to be installed on computers other than the one used to make the package" is a misconception.

The situation is just not so one-sided as you wrote it. I explain this:

First, let's put aside please the trust and security reasons. This is another and different question. A most important one, for sure, but another one. Let's speak only here about the technical value of a package made with checkinstall.

Checkinstall can technically be trusted, even for distribution purposes. It's part of the Ubuntu communautary documentation. Look here: https://help.ubuntu.com/community/CheckInstall which speaks of "allowing for easy package removal or distribution".
It has indeed some limitations,
- 32bits or 64 bits version
- same version of same distribution specially when there are dependencies
- same architecture (i386 or Sparc,...) written in the deb package.If available, I agree that an official package is to be preferred
- available for several architectures
- respect for specific distribution rules (recommended paths, icon menus, patches...)

So, for the above-mentioned reasons, the checkinstall built deb package I sent you can technically be trusted and it will successfully and safely run on all 32 bits i386 computers using Ubuntu jaunty and not only on my computer where it has been compiled and built.

It's somewhat more limited than what I wrote before and I apologize for this, but it's still significant and of much wider use than what you wrote. So, all done for the double misconception I wanted to correct.

To conclude, you wrote that to compile your program is trivial. Well, to create a working deb package with checkinstall including the needed dependencies is just as trivial. It's, to use your own words, “as simple as” replacing :sudo make install
bysudo checkinstall -D --requires="libqt4-gui,libqt4-svg,libqt4-webkit,libqt4-xml”
Note: for black magic reasons, no whitespace between package names, only comas.

This was my best shot too. Thank you for giving me the opportunity to understand better checkinstall and for having taken the time to reply.

I'm just new to Sigil, and using it for some hours for comparing with various editing and conversion tools supporting .epub. Looks really great and simple. Congratulations.

A simple question, sorry, but I was not able to find it in the forum (using search) or with first-look program options:

- How can I add a cover image? To show as cover, not in text, for all software and hardware .epub readers.

- And, how much must the size for this image? I noted that Sigil does not change or resize the images, so later in viewers they are too small, or too big.

- I have a strange problem: when saving/loading files, I can load again the .epub exported files, but not the original .sgf one (???) Hangs forever loading with high cpu usage, both are about 4,83 MB size.

By the way, I vote also for .RTF and .MOBI (.PRC) input and conversion. Later you can even consider .LRF, if not too tricky, considering the latest Sony news.