Package Details: qdirstat-git 1:1.8.1.r42.g8174478-1

Git Clone URL: https://aur.archlinux.org/qdirstat-git.git (read-only, click to copy)
Package Base: qdirstat-git
Description: GUI disk usage utility (successor to kdirstat)
Upstream URL: https://github.com/shundhammer/qdirstat
Keywords: disk_usage
Licenses: GPL2
Conflicts: qdirstat
Provides: qdirstat
Submitter: Morn
Maintainer: Morn (cyqsimon)
Last Packager: cyqsimon
Votes: 12
Popularity: 0.069579
First Submitted: 2016-02-20 16:05 (UTC)
Last Updated: 2023-10-19 04:16 (UTC)

Dependencies (2)

Required by (0)

Sources (1)

Latest Comments

1 2 Next › Last »

xiota commented on 2023-10-19 03:24 (UTC)

Thank you for updating. You have multiple other packages with similar issues as discussed here. I will let you find them on your own.

cyqsimon commented on 2023-10-19 03:22 (UTC)

@xiota You need to have your ego checked man. It's not healthy for you.

xiota commented on 2023-10-19 03:10 (UTC)

I just wanted to put you in your place first.

That's why I think you're an incompetent maintainer. Convince me I'm wrong by fixing the package.

cyqsimon commented on 2023-10-19 03:04 (UTC)

The biggest difference between we two are, I'm happy to be corrected; you are not. And that makes a world of difference. I do not want to continue arguing with you either, because as you said, my argument is pointless. Not because it's wrong, but because you have your mind made up.

I do intend to update pkgver as per your recommendation. I just wanted to put you in your place first.

xiota commented on 2023-10-19 02:38 (UTC) (edited on 2023-10-19 02:49 (UTC) by xiota)

The context is that this is an AUR package page. If it's not obvious to you that comments on this page pertain to AUR packages, qdirstat-git in particular, used on Arch Linux, you should probably not be maintaining the package.

Your argument is pointless. Ultimately, you agreed that removing the unnecessary package was the right thing to do, and you could have saved a lot of time by fixing the package in the first place.

You have ignored my previous mentions of pkgver() being noncompliant with VCS package guidelines. I will consider it to be intentional.

cyqsimon commented on 2023-10-19 02:30 (UTC) (edited on 2023-10-19 02:31 (UTC) by cyqsimon)

Okay now you're just being unnecessarily stubborn. If you are going to come here and make technical recommendations/corrections, you better first make sure you are technically correct. This is not some comedy club situation where you can get by with wishy-washy statements. Especially when you are so confident to say things like this:

The "truth" is not "somewhere in the middle". The section you quote confirms the statement you asked if I was sure about.

And no, I was not "intentionally misinterpreting your statement"; and no, it was not "obvious from context" what you now claim you actually meant. Remember when I thought your initial statement was problematic? Then I followed up asking for clarification and gave a counterexample, to which you replied the exact same thing, citing the wiki. I went to the wiki, realised it does not in fact say what you claim it says, pointed it out to you, but you still insisted you were infallible despite the contradiction. So I explained in detail why I believe your understanding is inaccurate, and now you are all defensive claiming I was trying to misconstrue your point. No, just no. You don't get away with twisting the timeline like this.

It seems like to me, you didn't correctly understand the technical details (which BTW, there's nothing wrong with that; nobody knows everything), and is now salty when someone corrects you. I mean, if you are correcting someone on a technicality, you'd better not act surprised when the reciprocal happens.

xiota commented on 2023-10-18 19:51 (UTC)

Your argument intentionally misinterprets my statement, which is not about conflicts in general, but how packages marked as conflicting are treated on Arch Linux, which is obvious from context.

pkgver() still needs to be updated to follow VCS guidelines (see my previous comment).

cyqsimon commented on 2023-10-18 14:22 (UTC) (edited on 2023-10-18 14:38 (UTC) by cyqsimon)

Okay. I agree with your assessment of what should be done in the particular case of this package, but I disagree with your generalisation. We can get to the bottom of this and reach a precise technical correctness consensus if you want. No hard feelings.

You initially said this:

All packages that conflict with the same package conflict with each other.

Logically this statement is most certainly false as is. The conflicts relation by itself has no reason to be transitive (see my previous counterexample). And if this were the case, there would be no need for a separate provides array because their semantics would be equivalent.

If the wiki is to be believed, the correct statement would instead be:

For all features F, any package that conflicts with F conflicts with all other packages that provide F.

So again, in this case, since both qdirstat-bin and qdirstat-git provide qdirstat explicitly, and qdirstat provides qdirstat implicitly, declaring conflicts=('qdirstat') is sufficient - this I agree. It's just I don't think the generalised reason you gave for this was correct.

In other words, the reason qdirstat-git (with only conflicts=('qdirstat') declared) would conflict with qdirstat-bin, is that qdirstat-bin has provides=('qdirstat'), not because qdirstat-bin has conflicts=('qdirstat').

xiota commented on 2023-10-18 13:40 (UTC) (edited on 2023-10-18 13:50 (UTC) by xiota)

5.2 conflicts.

The "truth" is not "somewhere in the middle". The section you quote confirms the statement you asked if I was sure about.

Also, pkgver() needs to be updated to use format #.r#.g#, in accordance with VCS package guidelines.

cyqsimon commented on 2023-10-18 12:56 (UTC) (edited on 2023-10-18 13:00 (UTC) by cyqsimon)

I am sure that all packages that (declare a) conflict with the same package (are) also (considered to) conflict with each other. It is described in more detail at PKGBUILD.

Where exactly does the wiki page say that? I cannot find it.

Edit: ah okay. So it does say this:

Hence, if your package provides a foo feature, specifying foo in the conflicts array will cause a conflict between your package and all other packages that contain foo in their provides array (i.e., you do not need to specify all those conflicting package names in your conflicts array).

I guess we are both partially correct. The truth (as per usual) is somewhere in the middle.