Package Details: q7z 0.9.1-2

Git Clone URL: (read-only)
Package Base: q7z
Description: An alternative 7-Zip GUI - replaced by the 'j7z' package
Upstream URL:
Licenses: LGPL3
Conflicts: k7z
Replaces: k7z
Submitter: None
Maintainer: Xavion
Last Packager: Xavion
Votes: 105
Popularity: 0.000009
First Submitted: 2007-09-05 21:08
Last Updated: 2015-06-08 23:46

Dependencies (7)

Required by (0)

Sources (1)

Latest Comments

Xavion commented on 2014-06-18 06:24

I'm not receiving that error here: this package still builds on my machine. Try re-downloading the source tarball, or just switch to the "j7z" package. To answer your question, Q7Z (in Qt) was replaced by J7Z (in Java).

oriba commented on 2014-06-18 00:29

is this package obsolete?
I got "ERROR: One or more files did not pass the validity check!"

And "replaced by the 'j7z' package" means, this package is deprecated?

Xavion commented on 2012-12-20 07:34

I have changed the URL as requested.

Xavion commented on 2012-12-18 09:36

Where does it state that on the ArchWiki? Also, are you saying that I must make this change?

keenerd commented on 2012-12-17 17:34

Please change the URL to
3rd party redirections are frowned upon.

schivmeister commented on 2011-07-21 18:23

That makes it all better :) Anyway, I'm sure many of us would like to thank you for this app - keep up the great work (now continued with J7Z).

Xavion commented on 2011-07-21 08:57

I've just added a prompt to the PKGBUILD for users to confirm that they want to ignore the deprecation warning and proceed to build this package anyway. This should offer the best compromise possible under the current limitation that AUR front-ends don't recognise the "replaces()" line properly.

Xavion commented on 2011-07-21 06:50

I thought it would be a bad idea to add a "provides=()" line to the J7Z PKGBUILD. Although J7Z provides most functionality of Q7Z, some things have been simplified and it's written in another language after all.

Total deprecation of Q7Z is what I've wanted ever since the release of J7Z in February. I can assure you that I did bump the 'pkgrel' variable (2) after the last normal Q7Z build (1) for the specific reason you've mentioned.

Since you've agreed that the presence of unfixed bugs justifies my handling of this matter, I've decided to keep the "return 1" line in place. I have replaced instances of 'msg' with 'warning' as suggested. I'm wondering if there's a 'question' alternative that would solve our dilemma. I should note that I can't see any mention of these (msg, warning, question) in the documentation.

As mentioned in my Feb 21 comment below, the absence of a "replacedby" or equivalent variable in PKGBUILDs is forcing me to redirect users manually. If I allow this package to build freely, some users won't bother to read the warnings and won't know that J7Z even exists.

I'm not worried that another user would bother to upload an alternative PKGBUILD, simply because they're annoyed at having to disable the "return 1" line. Doing something like that would be a sign of immaturity and their PKGBUILD should be removed by a TU promptly.

schivmeister commented on 2011-07-20 12:04

You're missing a "provides=()" in 'j7z'. Even though replacements don't work with AUR front-ends (since it's makepkg passing to pacman per pkg it'd be taken as a simple conflict), it's good to have those variables.

Yes, if what you want is total deprecation, then I agree this is a suitable workaround, but provided you bumped the pkgrel after the last normal 'q7z' build. A pkgrel bump would trigger an update to an AUR front-end, in turn relaying the message to the user.

I have nothing against the (quality of the) message, but rather how you break, or exit, the build after displaying it. Now that you talk about unfixed bugs, I'd agree that how you're handling this is fine. However, I still stand by my initial suggestion - you shouldn't break the build as long as the resulting application is functional and contains no security flaws. Simply display the message (important: using "warning" instead of "msg") and continue with the build.

If you instead choose to break the build like it is now, you provide others with a motive to upload an alternative PKGBUILD. I would much rather have only you maintaining such a PKGBUILD.

Xavion commented on 2011-07-20 06:38

You've raised a few good points there, which I'm happy to address in turn here. I'll start by noting that I had already added the relevant "conflicts()" and "replaces()" lines to the 'j7z' PKGBUILD when I first released it back in February.

Since even AUR front-ends don't recognise the "replaces()" line properly, I decided to take stronger action on this PKGBUILD instead. If I didn't do this, some users wouldn't realise that they should install the 'j7z' PKGBUILD instead.

I've provided instructions on how J7Z users can get it to look like their native desktop environment applications. They simply need to click on the "Get more skins ..." link and read all about it in the 'Skins' wiki article.

I don't particularly want people to keep using Q7Z, as it contains some unfixed bugs that I only noticed when testing J7Z. All of these reasons put together should lead a rational thinker to accept my decision to prevent this PKGBUILD from building by default.

Despite all of this, I understand what you're getting at and I've decided to soften the blow slightly. I've done this by adding another message line to the PKGBUILD that explains to users how they can go about defying my recommendation and building this package anyway.

schivmeister commented on 2011-07-19 19:44

I posted that comment with the full knowledge that you are the author. Notice that I mentioned "your software".

That does not give you the right to dictate or ammend packaging norms - was what I meant. You also have no right to "dictate" redistribution of your GPL'ed software; only recommend, suggest and advise. Sometimes, though, it's ethical and nice to follow an author's wishes, and in this/your case, we all do. But this is not the point I want to stress.

Breaking a PKGBUILD with messages is not recommended practice unless really, really required (like when a source can only be retrieved via restricted log-in procedures). In this case, the messages are unnecessary and you can simply leave this PKGBUILD alone, if you want all attention driven to J7Z. You can also add those relevant lines that I mentioned to J7Z.

I have no problem with J7Z (I use JDownloader and other Java apps with the same font issues), just your implied note about styling and how it could be an alternative to the native looks of a (Py)Qt app.

Xavion commented on 2011-07-18 21:56

Maybe you're not aware that I'm the author of Q7Z and J7Z. I thought this would give me the right to dictate which package is buildable.

If you take a look at this PKGBUILD, you'll notice that removing the disabled (#) and messaged lines will make this package buildable again.

It looks like you've tried J7Z and aren't happy with the font rendering. This is most likely a Java problem that I have no control over.

schivmeister commented on 2011-07-18 11:13

Pacman "recognises" replacements by the way of:


But of course, the AUR web interface cannot handle this. AUR front-ends may.

Anyway, I see no reason for you to be so anal about this (just leave it as-is without breaking the build with messages), as I see no reason for not forking Q7z, or even this PKGBUILD, or not redistributing your software in binary package form (which will result in not having it in the AUR; you may still choose to co-operate with the packager).

Btw, no matter which skin you go with, the font rendering remains ugly.

Xavion commented on 2011-02-28 01:46

J7Z can also adopt the system theme, even when run in Linux via Gnome/KDE/Xfce. More information about how to achieve this is available here:

Xavion commented on 2011-02-21 22:52

Since no "replacedby" or equivalent variable is recognised in PKGBUILDs, I must redirect users of this package to J7Z manually.

Anyone can still build and install this package. They just need to toggle the enabled state of the relevant lines in the PKGBUILD.

The JRE (94 MiB) is much smaller than Python, Qt and PyQt combined (191 MiB). This was one of the reasons why I decided to switch Q7Z to Java. Anyone who doesn't want to install the JRE can just use OpenJDK instead.

Anonymous comment on 2011-02-21 20:26

I think it would be better if the last version of Q7z remained fully buildable in AUR, as long as some people doesn't like installing big fat JRE in sake of one (even very useful) utility.

Xavion commented on 2011-02-19 23:04

Yes, I'm sorry to say that Q7Z has been deprecated. I know that there are some drawbacks with Java, but the positives outweighed them in this case.

I think J7Z's default 'Nimbus' skin is pretty good. It's definitely not the ugly Java skin that we're used to. J7Z can also detect and use custom skins.

Xavion commented on 2011-02-19 21:47

Yes, I'm sorry to say that Q7Z has been deprecated. I know that there are some drawbacks with Java, but the positives outweighed them in this case.

Anonymous comment on 2011-02-19 10:35

Is support for Q7z completely dropped? JRE version doesn't follow system theme, while python one does.

Xavion commented on 2011-02-17 05:40

This application has been replaced by J7Z. I created a 'j7z' package for your convenience.

Please don't delete this (q7z) package from the AUR, as I want it to stick around for a while.

Xavion commented on 2011-01-10 23:51

Yes, I upgraded the source code to Python v3 syntax a few weeks ago.

anonymous_user commented on 2011-01-10 19:30

Is this only compatible with python3 and not python2?

Xavion commented on 2010-11-14 22:15

Thanks for making me aware of this issue, which affected those without the 'python' package installed. I've added an extra 'sed' line to the PKGBUILD in order to fix the problem.

ranger commented on 2010-11-14 19:30

Cannot upgrade from 0.8.0-1 to -2

Xavion commented on 2010-11-09 06:25

There shouldn't be any need for this type of thing, as shell tab completion means that we only have to type "Q7<tab>" in order to get "Q7Z.pyw".

schivmeister commented on 2010-11-08 19:53

Or you could just include a symlink. In fact, I don't know why that has never been done. Makes life easier for us users at no cost :)

Xavion commented on 2010-09-28 06:55

I'd prefer to keep the ".pyw" extension for cross-platform consistency purposes. You can just "sudo ln -s /usr/bin/Q7Z.pyw /usr/bin/q7z" to get what you're wanting.

dracorp commented on 2010-09-27 19:08

Could you rename /usr/bin/Q7Z.pyw to /usr/bin/q7z for example?

Anonymous comment on 2010-09-26 03:42

Xavion commented on 2010-05-01 07:29

Since I'm the author of this application, I will always want this package to remain in the AUR.