Re: [aur-general] Tarball Guidelines
Hi all, been told by the bot, that selinux-flex has a binary (selinux-flex/flex- arch.patch.gz), which is a gziped patch. Guess I can ungzip it, though as this package is just a copy of a [core] package from some time ago, I guess the original maintainers new, what they were doing, if they included it this way. So should I do it to not include evil gziped patches? Thanx, Nicky -- Don't it always seem to go That you don't know what you've got Till it's gone (Joni Mitchell)
On Mon, Dec 6, 2010 at 4:59 AM, Nicky726 <nicky726@gmail.com> wrote:
been told by the bot, that selinux-flex has a binary (selinux-flex/flex- arch.patch.gz), which is a gziped patch. Guess I can ungzip it, though as this package is just a copy of a [core] package from some time ago, I guess the original maintainers new, what they were doing, if they included it this way. So should I do it to not include evil gziped patches?
Evil is such a strong word. It is just without benefit. Disturbs the transparency of things. Technically against the rules. Zipped patches was an edge case. Here, I chose to take a strict interpritation of the edge cases. It is only a comment after all, very little of consequence. Besides, Arch tries hard to not patch things :-) But thank you for taking the time to read and respond. So many maintainers ignore comments. -Kyle http://kmkeen.com
keenerd wrote:
On Mon, Dec 6, 2010 at 4:59 AM, Nicky726 <nicky726@gmail.com> wrote:
been told by the bot, that selinux-flex has a binary (selinux-flex/flex- arch.patch.gz), which is a gziped patch. Guess I can ungzip it, though as this package is just a copy of a [core] package from some time ago, I guess the original maintainers new, what they were doing, if they included it this way. So should I do it to not include evil gziped patches?
Evil is such a strong word. It is just without benefit. Disturbs the transparency of things. Technically against the rules.
Zipped patches was an edge case. Here, I chose to take a strict interpritation of the edge cases. It is only a comment after all, very little of consequence. Besides, Arch tries hard to not patch things :-)
But thank you for taking the time to read and respond. So many maintainers ignore comments.
-Kyle http://kmkeen.com
If the patch is large then what's the problem with compressing it?
On Tue 07 Dec 2010 16:49 +0100, Xyne wrote:
keenerd wrote:
On Mon, Dec 6, 2010 at 4:59 AM, Nicky726 <nicky726@gmail.com> wrote:
been told by the bot, that selinux-flex has a binary (selinux-flex/flex- arch.patch.gz), which is a gziped patch. Guess I can ungzip it, though as this package is just a copy of a [core] package from some time ago, I guess the original maintainers new, what they were doing, if they included it this way. So should I do it to not include evil gziped patches?
Evil is such a strong word. It is just without benefit. Disturbs the transparency of things. Technically against the rules.
Zipped patches was an edge case. Here, I chose to take a strict interpritation of the edge cases. It is only a comment after all, very little of consequence. Besides, Arch tries hard to not patch things :-)
But thank you for taking the time to read and respond. So many maintainers ignore comments.
If the patch is large then what's the problem with compressing it?
I would argue that we should not have large patches applied to Arch, or AUR packages at all. If there is enough patching, that constitues a fork, and we shouldn't be hosting project files for defacto forks on the AUR. They should find some other place to host their project. That large patch, and any other source tarballs should be downloadable from the project's webspace, not the AUR.
Loui Chang wrote:
If the patch is large then what's the problem with compressing it?
I would argue that we should not have large patches applied to Arch, or AUR packages at all. If there is enough patching, that constitues a fork, and we shouldn't be hosting project files for defacto forks on the AUR. They should find some other place to host their project. That large patch, and any other source tarballs should be downloadable from the project's webspace, not the AUR.
I mostly agree. I thought about my post afterwards and realized that there are very few cases in which a patch could be large enough to be worth compressing while simultaneously being appropriate for the AUR. There are probably some cases though in which large patches might be required to make something play nicely with Arch, i.e. something that isn't a fork but just a relatively large compatibility fix. I also just realized that compressing the archive itself probably makes compressing internal files redundant.
On Fri 10 Dec 2010 15:15 +0100, Xyne wrote:
Loui Chang wrote:
If the patch is large then what's the problem with compressing it?
I would argue that we should not have large patches applied to Arch, or AUR packages at all. If there is enough patching, that constitues a fork, and we shouldn't be hosting project files for defacto forks on the AUR. They should find some other place to host their project. That large patch, and any other source tarballs should be downloadable from the project's webspace, not the AUR.
I mostly agree. I thought about my post afterwards and realized that there are very few cases in which a patch could be large enough to be worth compressing while simultaneously being appropriate for the AUR.
There are probably some cases though in which large patches might be required to make something play nicely with Arch, i.e. something that isn't a fork but just a relatively large compatibility fix.
I also just realized that compressing the archive itself probably makes compressing internal files redundant.
Actually in the case of the current AUR implementation, it's actually nicer to have them compressed since it will require less resources from the server. That will change in the near future so that it won't make a difference.
On Mon 06 Dec 2010 10:59 +0100, Nicky726 wrote:
been told by the bot, that selinux-flex has a binary (selinux-flex/flex- arch.patch.gz), which is a gziped patch. Guess I can ungzip it, though as this package is just a copy of a [core] package from some time ago, I guess the original maintainers new, what they were doing, if they included it this way. So should I do it to not include evil gziped patches?
It would be best to avoid. It would be preferable to have the patch incorporated upstream if possible.
participants (4)
-
keenerd
-
Loui Chang
-
Nicky726
-
Xyne