[aur-general] nanoc3 deletion request

newer
[aur-general] Merge and deletion...

Jeremy Audet

6 Apr 2013 6 Apr '13

4:25 a.m.

I'm requesting the deletion of the AUR package nanoc3. [1] The AUR currently includes two similarly-named packages: nanoc and nanoc3. At one time, nanoc provided v2.x of the gem, and nanoc3 provided v3.x of the gem. [2] However, nanoc has supseded nanoc3. If you look at rubygems.org, you can see that the two development lines merged from 3.2.0 to 3.3.0. After the release of 3.3.0, nanoc3 releases stopped, whereas nanoc releases continued. [3][4] Thus, nanoc3 is no longer being developed, and it has been superseded. One last question: assuming the deletion request is approved, should the nanoc PKGBUILD both replace() and provide() nanoc3? If I understand correctly, the replace() would allow nanoc3 users a clean upgrade path, whereas the provide() would allow programs that depend on nanoc3 to use nanoc. (new package maintainer here, so still fleshing out my understanding of things) [1] https://aur.archlinux.org/packages/ruby-nanoc3/ [2] http://nanoc.ws/wiki-old/Development_3.1_BetterGemAndExecutableNames/ [3] https://rubygems.org/gems/nanoc/versions [4] https://rubygems.org/gems/nanoc3/versions -- Jeremy "Ichimonji10" Audet

Show replies by date

Xyne

6 Apr 6 Apr

3:33 p.m.

On 2013-04-06 00:25 -0400 Jeremy Audet wrote:

...

I'm requesting the deletion of the AUR package nanoc3. [1]

The AUR currently includes two similarly-named packages: nanoc and nanoc3. At one time, nanoc provided v2.x of the gem, and nanoc3 provided v3.x of the gem. [2] However, nanoc has supseded nanoc3. If you look at rubygems.org, you can see that the two development lines merged from 3.2.0 to 3.3.0. After the release of 3.3.0, nanoc3 releases stopped, whereas nanoc releases continued. [3][4]

Thus, nanoc3 is no longer being developed, and it has been superseded.

The package has been merged into ruby-nanoc. Thanks.

...

One last question: assuming the deletion request is approved, should the nanoc PKGBUILD both replace() and provide() nanoc3? If I understand correctly, the replace() would allow nanoc3 users a clean upgrade path, whereas the provide() would allow programs that depend on nanoc3 to use nanoc. (new package maintainer here, so still fleshing out my understanding of things)

Your understanding is correct.

Daniel Wallace

3:51 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xyne wrote:

...

On 2013-04-06 00:25 -0400 Jeremy Audet wrote:

...
I'm requesting the deletion of the AUR package nanoc3. [1]

The AUR currently includes two similarly-named packages: nanoc and nanoc3. At one time, nanoc provided v2.x of the gem, and nanoc3 provided v3.x of the gem. [2] However, nanoc has supseded nanoc3. If you look at rubygems.org, you can see that the two development lines merged from 3.2.0 to 3.3.0. After the release of 3.3.0, nanoc3 releases stopped, whereas nanoc releases continued. [3][4]

Thus, nanoc3 is no longer being developed, and it has been superseded.

The package has been merged into ruby-nanoc. Thanks.

...
One last question: assuming the deletion request is approved, should

...
nanoc PKGBUILD both replace() and provide() nanoc3? If I understand correctly, the replace() would allow nanoc3 users a clean upgrade

the path,

...
whereas the provide() would allow programs that depend on nanoc3 to use nanoc. (new package maintainer here, so still fleshing out my understanding of things)

Your understanding is correct.

Just remember there is actually no use for replaces in the aur. That directive is only useful in the regular repositories. Provides and conflicts is all you actually need for a clean update. Replaces is used by pacman to find if there is anything in the repositories that replaces something else. Like when we did all the renames of python packages. - -- Sent from my Android Phone. Daniel Wallace Arch Linux Trusted User GTManfred -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iQFUBAEBCAA+BQJRYESLNxxEYW5pZWwgV2FsbGFjZSAoZ3RtYW5mcmVkKSA8ZGFu aWVsLndhbGxhY2VAZ2F0ZWNoLmVkdT4ACgkQX6XlVE8BDUjutQf/V4h7qpYIChfG mBsQ6q6gCHzQTfySYg70zNqMUNKQmucs5LvCjhKG+jH9dPsdbGQRXloNNnbZItc7 d9QeyASKhIQ41MZn8kotAGM/sO0eMktChlL/9kiyeHq7w05Mxuj0X1C6p7UPtOxQ IGbeAA2brick1LmjvQGX/orTKnEa6IV+884c3yb/JhCzf6Q0OgB6BlPcS4TTC3Xd treddXQL4Ud/SiPrKzDxh5dEzfnC/dF9BdExEdlKTGKpUPAICFTEERVMR9EFv3C6 2W/J4XB7GTcoMksl7wjj50TERIwpTV3W/EQCFoc8tXA52v9DYWfXlZySD08p7NLP mJ8NpUywrA== =6fr8 -----END PGP SIGNATURE-----

Jeremy Audet

6:22 p.m.

...

Just remember there is actually no use for replaces in the aur. That directive is only useful in the regular repositories. Provides and conflicts is all you actually need for a clean update.

Replaces is used by pacman to find if there is anything in the repositories that replaces something else. Like when we did all the renames of python packages.

Thanks for the tip. I had no idea that `replaces` was only useful in the reular repositories. I'll add a `conflicts` directive to the ruby-nanoc package.

Xyne

9:19 p.m.

On 2013-04-06 14:22 -0400 Jeremy Audet wrote:

...

...
Just remember there is actually no use for replaces in the aur. That directive is only useful in the regular repositories. Provides and conflicts is all you actually need for a clean update.

Replaces is used by pacman to find if there is anything in the repositories that replaces something else. Like when we did all the renames of python packages.

Thanks for the tip. I had no idea that `replaces` was only useful in the reular repositories. I'll add a `conflicts` directive to the ruby-nanoc package.

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. 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. Regards, Xyne

Andrew Gregory

9:37 p.m.

On 04/06/13 at 09:19pm, 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.

I really hope there aren't any AUR helpers out there that support "replaces". That would require downloading the PKGBUILD for every single package in the AUR... apg

Xyne

9:53 p.m.

Andrew Gregory wrote:

...

On 04/06/13 at 09:19pm, 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.

I really hope there aren't any AUR helpers out there that support "replaces". That would require downloading the PKGBUILD for every single package in the AUR...

apg

There have been some attempts to provide a git repo of the entire AUR which would contain that information. 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. Finally, with the advent of the extra metadata in uploaded archives it may well be possible and even trivial to add support for resolving providers and replacements via the various AUR interfaces in the future. When given the choice between a rigorous approach and a lazy approach with no significant cost difference between them, you should choose the rigorous approach to avoid incurring additional costs in the future. It's simply good practice and I do not understand why rigor is met with such resistance. Regards, Xyne

Daniel Wallace

10:01 p.m.

On Sat, Apr 06, 2013 at 09:19:09PM +0000, Xyne wrote:

...

On 2013-04-06 14:22 -0400 Jeremy Audet wrote:

...
...
Just remember there is actually no use for replaces in the aur. That directive is only useful in the regular repositories. Provides and conflicts is all you actually need for a clean update.

Replaces is used by pacman to find if there is anything in the repositories that replaces something else. Like when we did all the renames of python packages.

Thanks for the tip. I had no idea that `replaces` was only useful in the reular repositories. I'll add a `conflicts` directive to the ruby-nanoc package.

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.

...

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

10:31 p.m.

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:

...
On 2013-04-06 14:22 -0400 Jeremy Audet wrote:

...
...
Just remember there is actually no use for replaces in the aur. That directive is only useful in the regular repositories. Provides and conflicts is all you actually need for a clean update.

Replaces is used by pacman to find if there is anything in the repositories that replaces something else. Like when we did all the renames of python packages.

Thanks for the tip. I had no idea that `replaces` was only useful in the reular repositories. I'll add a `conflicts` directive to the ruby-nanoc package.

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

Jason St. John

10:50 p.m.

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

Jeremy Audet

8 Apr 8 Apr

1:04 p.m.

...

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 wrote:

...

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

4045

Age (days ago)

4047

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Andrew Gregory
Daniel Wallace
Jason St. John
Jeremy Audet
Xyne