Can we get more explanation for this? This isn't a version bump. This project was rewritten from scratch, the old sources are gone. The PKGBUILD was written from scratch, packagement solutions were upstreamed[1]. Upstream points specifically to this package[2]. Archlinux repo maintainer wasn't involved at all with those and there is no info if he's interested in maintaining the new v2 version.
[1] https://github.com/jedisct1/dnscrypt-proxy/commit/fa2c95084ef9b575bfbe62543e... [2] https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux
Jordan
On 04/04/2018 02:41 PM, Jordan Glover via aur-general wrote:
Can we get more explanation for this? This isn't a version bump. This project was rewritten from scratch, the old sources are gone. The PKGBUILD was written from scratch, packagement solutions were upstreamed[1]. Upstream points specifically to this package[2]. Archlinux repo maintainer wasn't involved at all with those and there is no info if he's interested in maintaining the new v2 version.
[1] https://github.com/jedisct1/dnscrypt-proxy/commit/fa2c95084ef9b575bfbe62543e... [2] https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux
Jordan
It's got the same name, is written by the same author, and the versions begin at 2.0.0. Fwiw this is just a major version bump of the same package - it doesn't really matter what percentage of it has changed since the last version. Yes, that means the package in [community] is out-of-date, and no, your involvement with upstream doesn't matter.
Regards, Rob
On April 4, 2018 3:44 PM, Robin Broda via aur-general aur-general@archlinux.org wrote:
On 04/04/2018 02:41 PM, Jordan Glover via aur-general wrote:
Can we get more explanation for this? This isn't a version bump. This project
was rewritten from scratch, the old sources are gone. The PKGBUILD was written
from scratch, packagement solutions were upstreamed[1]. Upstream points
specifically to this package[2]. Archlinux repo maintainer wasn't involved at
all with those and there is no info if he's interested in maintaining the new
v2 version.
[1] https://github.com/jedisct1/dnscrypt-proxy/commit/fa2c95084ef9b575bfbe62543e...
[2] https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux
Jordan
It's got the same name, is written by the same author, and the versions
begin at 2.0.0. Fwiw this is just a major version bump of the same
package - it doesn't really matter what percentage of it has changed
since the last version.
So when it doesn't share any code, doesn't share code repository and doesn't use compatible configs it's still the same package but when it shares the same code, repository and configs and it's named securedns-proxy it will be totally different.
Yes, that means the package in [community] is out-of-date, and no, your
involvement with upstream doesn't matter.
I'm not the package owner.
Regards, Rob
The point is that the community package which doesn't build manually and point to nonexistent sources is the one which should be deleted instead of the one from AUR. If you prefer that upstream Archlinux instructions will look the same as those for Ubuntu/Debian[*] then it will be done but it would mean that Archlinux project in current form is a joke and you role in it isn't worth a dime.
[*] "Do not install the dnscrypt-proxy distribution package, as it is old, and unsupported." https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-Debian-Ubuntu Jordan
On 04/04/2018 04:37 PM, Jordan Glover wrote:
On April 4, 2018 3:44 PM, Robin Broda via aur-general aur-general@archlinux.org wrote:
On 04/04/2018 02:41 PM, Jordan Glover via aur-general wrote:
Can we get more explanation for this? This isn't a version bump. This project
was rewritten from scratch, the old sources are gone. The PKGBUILD was written
from scratch, packagement solutions were upstreamed[1]. Upstream points
specifically to this package[2]. Archlinux repo maintainer wasn't involved at
all with those and there is no info if he's interested in maintaining the new
v2 version.
[1] https://github.com/jedisct1/dnscrypt-proxy/commit/fa2c95084ef9b575bfbe62543e...
[2] https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux
Jordan
It's got the same name, is written by the same author, and the versions
begin at 2.0.0. Fwiw this is just a major version bump of the same
package - it doesn't really matter what percentage of it has changed
since the last version.
So when it doesn't share any code, doesn't share code repository and doesn't use compatible configs it's still the same package ...
This is a result of the poor deprecation path (read: none) dnscrypt-proxy v1 had, coupled with the poor handling of superseding it with v2 (deleting all traces to v1, developing v2 in the same namespace). That's just bad project management, and there's no reason to rename our community/dnscrypt-proxy when (the same) upstream calls itself dnscrypt-proxy v2 - it's, for all that matters, a major version bump with breaking changes and an awful deprecation path.
... but when it shares the same code, repository and configs and it's named securedns-proxy it will be totally different.
IMO, if this was a new program officially called securedns-proxy, on a different upstream URL, then yes - that'd be a new package.
Yes, that means the package in [community] is out-of-date, and no, your
involvement with upstream doesn't matter.
I'm not the package owner.
Regards, Rob
The point is that the community package which doesn't build manually and point to nonexistent sources is the one which should be deleted instead of the one from AUR. If you prefer that upstream Archlinux instructions will look the same as those for Ubuntu/Debian[*] then it will be done but it would mean that Archlinux project in current form is a joke and you role in it isn't worth a dime.
The package in [community] will be updated soon.
[*] "Do not install the dnscrypt-proxy distribution package, as it is old, and unsupported." https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-Debian-Ubuntu Jordan
Regards, Rob
On April 4, 2018 4:49 PM, Robin Broda via aur-general aur-general@archlinux.org wrote:
On 04/04/2018 04:37 PM, Jordan Glover wrote:
The point is that the community package which doesn't build manually and
point to nonexistent sources is the one which should be deleted instead of
the one from AUR. If you prefer that upstream Archlinux instructions will look
the same as those for Ubuntu/Debian[*] then it will be done but it would mean
that Archlinux project in current form is a joke and you role in it isn't worth a
dime.
The package in [community] will be updated soon.
Jordan
Regards, Rob
I'm sorry for the harsh words. If those requests were made AFTER update package in repo there won't be this conversation. I found situation where killing other people efforts to make things work, unacceptable without providing an alternative. Common sense should prevail the rules.
Jordan
On Wed, 04 Apr 2018 11:23:34 -0400 Jordan Glover via aur-general aur-general@archlinux.org wrote:
I'm sorry for the harsh words. If those requests were made AFTER update package in repo there won't be this conversation. I found situation where killing other people efforts to make things work, unacceptable without providing an alternative. Common sense should prevail the rules.
Jordan
Common sense tells me that if we allow people to upload newer packages just because the repo package is out of date, the AUR will be an even bigger mess than it already is. Everyone will be uploading packages a few hours after upstream releases updates, and of course they will just abandon them instead of having them deleted. The rules are in place for a reason.
Doug
On April 4, 2018 5:32 PM, Doug Newgard scimmia@archlinux.org wrote:
On Wed, 04 Apr 2018 11:23:34 -0400
Jordan Glover via aur-general aur-general@archlinux.org wrote:
I'm sorry for the harsh words. If those requests were made AFTER update package
in repo there won't be this conversation. I found situation where killing other people
efforts to make things work, unacceptable without providing an alternative. Common
sense should prevail the rules.
Jordan
Common sense tells me that if we allow people to upload newer packages just
because the repo package is out of date, the AUR will be an even bigger mess
than it already is. Everyone will be uploading packages a few hours after
upstream releases updates, and of course they will just abandon them instead of
having them deleted. The rules are in place for a reason.
Doug
Please be specific. We aren't talking about hours and bumping package version. Common sense can be used to know when taking action will make people worse-off. The package was managed so efficiently that even upstream benefited from it. Archlinux maintainer dosen't have to do anything else than copy-paste existing PKGBUILD. All work and testing is already done.
Jordan
On Wed, 04 Apr 2018 11:54:33 -0400 Jordan Glover via aur-general aur-general@archlinux.org wrote:
On April 4, 2018 5:32 PM, Doug Newgard scimmia@archlinux.org wrote:
On Wed, 04 Apr 2018 11:23:34 -0400
Jordan Glover via aur-general aur-general@archlinux.org wrote:
I'm sorry for the harsh words. If those requests were made AFTER update package
in repo there won't be this conversation. I found situation where killing other people
efforts to make things work, unacceptable without providing an alternative. Common
sense should prevail the rules.
Jordan
Common sense tells me that if we allow people to upload newer packages just
because the repo package is out of date, the AUR will be an even bigger mess
than it already is. Everyone will be uploading packages a few hours after
upstream releases updates, and of course they will just abandon them instead of
having them deleted. The rules are in place for a reason.
Doug
Please be specific. We aren't talking about hours and bumping package version. Common sense can be used to know when taking action will make people worse-off. The package was managed so efficiently that even upstream benefited from it. Archlinux maintainer dosen't have to do anything else than copy-paste existing PKGBUILD. All work and testing is already done.
Jordan
I have been specific; the rules are in place for a reason, common sense says that they're necessary. This case is not special.
C&Ping the entire PKGBUILD would be a huge mistake. Those sed commands are...marginal, to be generous.
AUR is like the wild west. Anyone can upload any packages even if it is already exist.
On Wed, Apr 4, 2018 at 4:01 PM, Doug Newgard via aur-general < aur-general@archlinux.org> wrote:
On Wed, 04 Apr 2018 11:54:33 -0400 Jordan Glover via aur-general aur-general@archlinux.org wrote:
On April 4, 2018 5:32 PM, Doug Newgard scimmia@archlinux.org wrote:
On Wed, 04 Apr 2018 11:23:34 -0400
Jordan Glover via aur-general aur-general@archlinux.org wrote:
I'm sorry for the harsh words. If those requests were made AFTER
update package
in repo there won't be this conversation. I found situation where
killing other people
efforts to make things work, unacceptable without providing an
alternative. Common
sense should prevail the rules.
Jordan
Common sense tells me that if we allow people to upload newer packages
just
because the repo package is out of date, the AUR will be an even
bigger mess
than it already is. Everyone will be uploading packages a few hours
after
upstream releases updates, and of course they will just abandon them
instead of
having them deleted. The rules are in place for a reason.
Doug
Please be specific. We aren't talking about hours and bumping package
version.
Common sense can be used to know when taking action will make people
worse-off.
The package was managed so efficiently that even upstream benefited from
it.
Archlinux maintainer dosen't have to do anything else than copy-paste
existing
PKGBUILD. All work and testing is already done.
Jordan
I have been specific; the rules are in place for a reason, common sense says that they're necessary. This case is not special.
C&Ping the entire PKGBUILD would be a huge mistake. Those sed commands are...marginal, to be generous.
On 04/04/2018 01:05 PM, alrii via aur-general wrote:
AUR is like the wild west. Anyone can upload any packages even if it is already exist.
They sure can, and we can delete the package -- and the user with it.
...
The dnscrypt-proxy-go-git is pretty obviously a duplicate of dnscrypt-proxy-git. I've told the git maintainer to update with the original, now rewritten upstream sources.
*This is now over and done with.*
The dnscrypt-proxy package is now updated, and I graciously left the dnscrypt-proxy-go package available until now... because it started as the golang beta which was something valid to have in the AUR, and I wasn't sure I wanted to delete the existing package before it was otherwise available. If it had been newly uploaded it would be deleted in a heartbeat -- it would hardly be the first outdated package that was uploaded to the AUR and deleted for breaking the rules.
(Why is the peanut gallery complaining about a deletion request that had not even been accepted.)
*This too is now over and done with.*
Anyone who wants the 1.x version is welcome to create a dnscrypt-proxy-legacy{,-git} package.
On 2018-04-04 11:01:20 (-0500), Doug Newgard via aur-general wrote:
Please be specific. We aren't talking about hours and bumping package version. Common sense can be used to know when taking action will make people worse-off. The package was managed so efficiently that even upstream benefited from it. Archlinux maintainer dosen't have to do anything else than copy-paste existing PKGBUILD. All work and testing is already done.
Jordan
I have been specific; the rules are in place for a reason, common sense says that they're necessary. This case is not special.
C&Ping the entire PKGBUILD would be a huge mistake. Those sed commands are...marginal, to be generous.
While being in line with what Doug wrote on the topic, I agree, that it took quite some time to upgrade, but behold! dnscrypt-proxy 2.0.8 is now in community-testing (btw: no, not just c/p) [1]. I do understand that a longer wait time can be frustrating for users, but it's no reason to get aggressive about it. The upstream situation was far from "easy going" IMHO, which was all the more reason to wait and see what would happen.
A few (unpaid) hands are trying to keep up the shape of what Arch is. I have the feeling, that sometimes it is easily forgotten, that we are a community of like-minded (and from what I read, passionate) people. If you find a problem, go ahead and fix it (e.g. by applying to become a TU and engaging in the overall quality of the distribution), but please keep in mind, that we're all doing this in our free time.
[1] https://www.archlinux.org/packages/community-testing/x86_64/dnscrypt-proxy/
On April 5, 2018 12:50 AM, David Runge dave@sleepmap.de wrote:
While being in line with what Doug wrote on the topic, I agree, that it
took quite some time to upgrade, but behold! dnscrypt-proxy 2.0.8 is now
in community-testing (btw: no, not just c/p) [1].
I do understand that a longer wait time can be frustrating for users,
but it's no reason to get aggressive about it.
I wasn't complaining about outdated package or maintainer activity. In fact AUR alternative provided pretty smooth transition period for many users.
The upstream situation was far from "easy going" IMHO, which was all the
more reason to wait and see what would happen.
A few (unpaid) hands are trying to keep up the shape of what Arch is. I
have the feeling, that sometimes it is easily forgotten, that we are a
community of like-minded (and from what I read, passionate) people. If
you find a problem, go ahead and fix it (e.g. by applying to become a
TU and engaging in the overall quality of the distribution), but please
keep in mind, that we're all doing this in our free time.
It's even easier to forgot that Arch users community is unpaid and passionate as well and throw their work out of the window just because you can. Did AUR maintainer benefited from uploading his package there? Not at all. They could use it locally just fine and don't care if anyone else need it to.
I spend an absurd amount of time for submitting bugs and enchantments to Arch packages, helping others, resolving Arch related issues with upstream and was the last person who benefited from it. Many Arch users voluntarily do the same things. And they don't have to have some meaningless title to feel special about it even when their work is treated as annoying disturbance because lack of it.
Jordan
On 04/05/2018 08:19 AM, Jordan Glover via aur-general wrote:
It's even easier to forgot that Arch users community is unpaid and passionate as well and throw their work out of the window just because you can. Did AUR maintainer benefited from uploading his package there? Not at all. They could use it locally just fine and don't care if anyone else need it to.
I spend an absurd amount of time for submitting bugs and enchantments to Arch packages, helping others, resolving Arch related issues with upstream and was the last person who benefited from it. Many Arch users voluntarily do the same things. And they don't have to have some meaningless title to feel special about it even when their work is treated as annoying disturbance because lack of it.
Lo and behold, that package was *not deleted* until it had a viable replacement in community-testing. What, exactly, are you complaining about?
The git version was very clearly a duplicate of the other AUR package which is under community user control. The maintainer needs to fix it properly (we'd be happy to orphan it if that is what it takes).
Many Arch users seem to forget, that uploading something to the AUR does more harm than good if it means nobody can figure out which of six different packages they are supposed to use. *This* is the reason duplicates are not allowed, not some arcane desire to "throw their work out of the window just because you can" or how good it presumably feels to publicly use "some meaningless title to feel special".
Did you have some reason to post, other than to see how far you can go insulting the Trusted Users by accusing us of being petty people who delight in deleting the work of others for the sheer delight of causing other people mental anguish?
aur-general@lists.archlinux.org