Xyne wrote: In general, PKGBUILDs uploaded to the AUR should adhere to all standards in such a way that they could be moved into a repo without further changes. Omitting key variables just because the AUR lacks support for them is a bad idea in my opinion.
This makes sense to me. If packages both inside and outside the AUR can be packaged the same way, they should be, even if certain parameters aren't currently efficacious in the AUR. Let's say that ruby-nanoc got moved into the community repo. If ruby-nanoc `replaces` ruby-nanoc3, then ruby-nanoc3 users will be provided with a clean upgrade path. This is desirable. (and, on a semantic level, `replaces` serves as a form of documentation)
Daniel Wallace wrote: Except if we look at the guidelines for submitting to the AUR. There is a nice note that they should never use replaces.
https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Submitting_pac...
#6, you can't miss it.
Aaaah, now *this* is the heart of the matter. ruby-nanoc does not merely conflict with ruby-nanoc3, it actually does replace ruby-nanoc3. jdk7-openjdk. [1] is a good example: it `conflicts` with java-environment and `replaces` openjdk6. However, the wiki implies that both `conflicts` and `replaces` produce the same result. (how?) That is, `replaces` is just a higher-priority version of `conflicts`. (in what way?) Is there a way we can get a clarification about this? I don't know where next to turn.
Daniel Wallace wrote: Why would you ever build a repository from straight aur packages. I don't know about you, but there is no one I trust enough to just build with there PKGBUILD for my repository. I keep a nice list of PKGBUILDs and build from those as I also maintain them.
Making a repo out of straight AUR packages may look stupid to you and I, but if someone wants to, that's their perogative. You and I shouldn't be dictating what other folks are allowed to do. After all, "Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system."
Xyne wrote: It would not be difficult to write a heuristic search algorithm to scan for potential replacements either (e.g. searching for "nanoc" returns two hits) upon detecting that a package is no longer available.
Yikes. I don't want my system's state to depend upon some heuristic algorithm. The state of a system should be predictable. But if the AUR itself was able to quickly answer queries such as "what replaces package X", or if some other solution arose (you mentioned something about metadata), that would be cool. [1] https://www.archlinux.org/packages/extra/x86_64/jdk7-openjdk/ On Sat, Apr 6, 2013 at 6:50 PM, Jason St. John <jstjohn@purdue.edu> wrote:
On Sat, Apr 6, 2013 at 6:31 PM, Daniel Wallace <danielwallace@gtmanfred.com> wrote:
On Sat, Apr 06, 2013 at 06:01:44PM -0400, Daniel Wallace wrote:
On Sat, Apr 06, 2013 at 09:19:09PM +0000, Xyne wrote:
I disagree that "replaces" is not useful in the AUR. Many people
create their
own repositories with AUR packages and then it is very useful. Some AUR helpers may support "replaces" as well.
Why would you ever build a repository from straight aur packages. I don't know about you, but there is no one I trust enough to just build with there PKGBUILD for my repository. I keep a nice list of PKGBUILDs and build from those as I also maintain them.
In general, PKGBUILDs uploaded to the AUR should adhere to all
standards in
such a way that they could be moved into a repo without further changes.
Except if we look at the guidelines for submitting to the AUR. There is a nice note that they should never use replaces.
https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Submitting_pac...
#6, you can't miss it.
Scratch that, I miss interpreted what it was saying, but that section should really be rewritten. It really shouldn't be talking about pacman -S because that is not something that really matters in the AUR.
But to the point that started this, you do not need replaces to do a clean update between the 2 packages for the rename, you only need conflicts (if there is something being built against it, you may need provides, or to just rebuild the other package once the first has been updated.)
Omitting key variables just because the AUR lacks support for them is
a bad
idea in my opinion.
Regards, Xyne
-- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology
-- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology
I would help clean up that section, but the article is not open to editing, even for ArchWiki Maintainers.
Jason