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: 103
Popularity: 0.000000
First Submitted: 2007-09-05 21:08
Last Updated: 2015-06-08 23:46

Dependencies (7)

Required by (0)

Sources (1)

Latest Comments

1 2 3 Next › Last »

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.