Arch Linux User Repository

The original source link is broken. But luckily I've saved a mirror on github.

I'm using the mirror link for now. Please remind me if the original link is available again.

Prebuilt binary of this package can be found in the arch4edu repository.

All your 'current patch' is my c code modification, which is a single file for a reason. The reason is to increase SGE usage and make other Linux distribution administrator life easier.

You are not reading my words. Commonly the reason of merging patches should be a bug report or an update of a package.

Here by SGE, I mean Some Grid Engine at https://github.com/daimh/sge

You are showing no respect to me. I've said three times that do not use SGE as the abbreviation for 'some grid engine' in any Son of Grid Engine or sun grid engine pages. And you don't read or follow. Besides, you are consistently using offensive words and making inproper requests even I've explained the reason many times.

Your furture comments won't be replied. Please do something that really benefits SGE such as helping to re-organize the current patches by the actual reason that breaks the build, such as a bug report or the update of gcc from version 7 to 8. And stop wasting my time.

All your 'current patch' is my c code modification, which is a single file for a reason. The reason is to increase SGE usage and make other Linux distribution administrator life easier.

Here by SGE, I mean Some Grid Engine at

https://github.com/daimh/sge

I am sorry I am referring to all kinds of SGE, which including sun, son, or some. If you have a problem with it, please report me or enlighten me with any rule.

I've fixed the description of this package. Now it's limited to Son of Grid Engine only. Please do not comment about sun grid engine or 'some grid engine' in this page anymore.
Besides, please do not use SGE as the abbreviation for 'some grid engine' in any Son of Grid Engine or sun grid engine pages. This is the 3rd time I'm saying this.

enlighten me if there is any new SGE patch file other than mine since Liverpool.

That's not the reason that the current patches should be merged into one. Commonly it should be a bug report or an update of a package.

I am sorry I am referring to all kinds of SGE, which including sun, son, or some. If you have a problem with it, please report me or enlighten me with any rule.

I agree merging two unrelated patch files into one is not good.

But enlighten me if there is any new SGE patch file other than mine since Liverpool.

Further, we are talking about not splitting a patch file into any small ones. Don't change the subject please.

Got it! An intolerable mistake can be just a side effect, depending on who made it. Geez, I am helping you and SGE, don't be so defensive....

I don't want to reply on these anymore. And these words are not helping neither me nor SGE.

I guess you mean some one else release a patch file to fix some new SGE compiling error? Merging two patch files is as simple as three commands, Two patch and one diff.

You are missing the point. As I have explained a lot, don't merge patch files when they are not relative.

Your multiple patch files are limiting SGE to Arch Linux users.

That's why I leave the patches here rather than submitting them to the upstream.

Even if someday you modified the code yourself, it is hard to see your contribution helps the rest of the Linux world.

I think there is no limitations for other linux users to access the patch files on AUR. Well organizing and well documenting patches as much as possible are just what we can to benefit the rest of the Linux world.

Got it! An intolerable mistake can be just a side effect, depending on who made it.

"there will be patches found by the exact reason causing errors such as gcc11.patch"

I guess you mean some one else release a patch file to fix some new SGE compiling error?

Merging two patch files is as simple as three commands, Two patch and one diff.

Your multiple patch files are limiting SGE to Arch Linux users, which are never mainstream SGE users and most likely won't be. Even if someday you modified the code yourself, it is hard to see your contribution helps the rest of the Linux world.

Geez, I am helping you and SGE, don't be so defensive....

You are in not any authority to tell other to name a software.

As the maintainer of sge on AUR, I do have the authority to recommend you that please don't use 'sge' as the name, the short name or part of name for 'some grid engine' on AUR.

you are the one made the pkgver mistake. See the comment by a821.

This is just a side effect for correcting your previous wrong pkgver. I don't want to discuss about this any more. It has nothing good to this package.

A 'diff -r' can easily find what files are changed.

That's true for now I just organize the patches by file. Because the patches are found by finding the first file raising errors during the compilation. But it doesn't mean it will be only by file. In the future there will be patches found by the exact reason causing errors such as gcc11.patch which your "half a century" old method won't be suitable anymore.

a order of magnitude compiling time reduce can be helpful.

I'll keep using the compilation method documented by the upstream if possible which should also be a principle for maintaining packages for Archlinux at least and the other linux distributions.

Besides, after setting '-j' in /etc/makepkg.conf, the building process is already greatly accelerated on a multi-core machine. Further small acceleration by changing the documented compilation method may not worth it.

Yes, I can name the software to whatever I want. You are in not any authority to tell other to name a software. Remember, you are the one made the pkgver mistake and you said this is intolerable.... See the comment by a821. :)

I don't know how one big patch file can make maintenance hard. A 'diff -r' can easily find what files are changed, not to mention this is a standard way for probably half a century.

Anyway, feel free to pull whatever new improvement in github, if you think a order of magnitude compiling time reduce can be helpful. Again, thanks for using my C code modification. Happy maintaining!

https://github.com/daimh/sge

I just changed it to 'some grid engine' on my github repo.

Okay, whatever. Sun grid engine is officially deprecated. Son of grid engine is not. So please don't use sge as the short name for your "some grid engine". If you want a package for your "some grid engine", please name it as some-grid-engine.

Why so many Linux administrators from CentOS and Debian read Arch Linux wiki these days? Arch Linux developer think in other people's shoes. Your way is not easy for other distribution administrators.

Take care your own shoes before taking care of the others. This is Archlinux user repository, not Anylinux user repository. Also a one-big patch file obviously make it hard to check the changes and follow this package on other distributions either. Some changes may not be needed on other distributions. Splitting them into patches will help the maintainers generating their own suitable patching strategies for their distributions. Directly copying and using an one-big patch without a double check, that's not maintaining at all.