Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.

FS#6446 - makepkg shouldn't allow '=' in dependencies

Attached to Project: Pacman
Opened by Scott H (stonecrest) - Sunday, 18 February 2007, 02:58 GMT
Last edited by Roman Kyrylych (Romashka) - Sunday, 18 February 2007, 12:39 GMT
Task Type Feature Request
Status Closed
Assigned To Dan McGee (toofishes)
Architecture not specified
Severity Medium
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Someone built a package with 'flac=1.1.2' as a dependency. This means that it doesn't work with my current version of flac, which is 1.1.2-3. Why would you ever use 'foo=X.X'? That would require you to know that the package doesn't work with future versions of foo, because otherwise you would have used '>='.

In my opinion, makepkg shouldn't ever allow '=' in dependencies, only '>=' or '<='. If there is a situation I haven't thought of, maybe a warning stressing how bad '=' is would suffice. But really, '=' should rarely, if ever, be used in a PKGBUILD.
This task depends upon

This task blocks these from closing
 FS#6316 - Pacman 3 release bugcatcher 
Closed by  Dan McGee (toofishes)
Sunday, 18 February 2007, 21:22 GMT
Reason for closing:  Won't implement
Additional comments about closing:  The bug is fixed where pkgrel is no longer read. However, the = operator is useful as JGC stated, so we do not want to remove it.
Comment by Roman Kyrylych (Romashka) - Sunday, 18 February 2007, 12:44 GMT
See also:
pacman2 can do -Su correctly in that case, while pacman3 cannot.

I think = can be used, but $pkgrel should not matter, only $pkgver.
Comment by Scott H (stonecrest) - Sunday, 18 February 2007, 17:52 GMT
I agree that only $pkgver should matter. But even still, if flac 1.1.3 were to come out, it would once again render the package useless. Surely the person who created the package wasn't implying that their package only works with the current flac and not future versions of flac, for how would they know?
Comment by Aaron Griffin (phrakture) - Sunday, 18 February 2007, 18:13 GMT
I agree with stonecrest here. Anyone else have an opinion?
Comment by Jan de Groot (JGC) - Sunday, 18 February 2007, 18:14 GMT
flac 1.1.3 or whatever they have is out, and that will sure render all flac packages useless: they rewrote the whole FLAC API in that. Flac 1.1.1 -> 1.1.2 was also such a problem, so flac=1.1.2 isn't a bad dependency, it's actually the right thing to do: it will only work with 1.1.2, nothing before, nothing after.
Comment by Roman Kyrylych (Romashka) - Sunday, 18 February 2007, 21:04 GMT
Yep, JGC is right (I followed his comments about flac in other reports too).
In this case = is exactly what is needed.
But nevertheless this is a bug in pacman3 that doesn't allow update while there _is_ flac-1.1.2 already.
So I suggest to change this feature request to bug report.
Comment by Roman Kyrylych (Romashka) - Sunday, 18 February 2007, 21:07 GMT
The bug is fixed in CVS already.
As per JGC's comment, this FR should be closed as "Won't Implement" IMO, because = is needed too.