[aur-general] nanoc3 deletion request

[Jeremy Audet]

> 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_packages_to_the_AUR
>
> #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 at purdue.edu> wrote:

> On Sat, Apr 6, 2013 at 6:31 PM, Daniel Wallace
> <danielwallace at 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_packages_to_the_AUR
> >>
> >> #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
>