Difference between revisions of "Talk:Improving performance/Boot process"

From ArchWiki
Jump to: navigation, search
(Readahead on AUR: now I see it)
Line 45: Line 45:
 
:::::::It was me who deleted the section. If a package is deleted from the AUR, related content is deleted from the wiki; an undiscussed reupload is no proper justification to re-add it.
 
:::::::It was me who deleted the section. If a package is deleted from the AUR, related content is deleted from the wiki; an undiscussed reupload is no proper justification to re-add it.
 
:::::::Now if you want to reply to an AUR request, contact the TU who accepted it. His email is linked from the mailing list thread, as well as in [[Trusted User]]. Return here after you've done so. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:48, 7 March 2015 (UTC)
 
:::::::Now if you want to reply to an AUR request, contact the TU who accepted it. His email is linked from the mailing list thread, as well as in [[Trusted User]]. Return here after you've done so. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:48, 7 March 2015 (UTC)
 +
 +
::::::::So, I talked with [[User:Jleclanche]] yesterday early and after a bit of back and forth we seemed to agree that this was a chain of misunderstandings. First of all, nobody really bothered to test it, blindly trusting each other in the process. Secondly, I'm not forking the whole systemd, you all seemed to think that my package was replacing parts of the monolithic systemd binary with a broken, limited version of it, sort of like a half-assed backport, that is simply not true.
 +
 +
::::::::The ''systemd-readahead'' binary (which is the only compiled executable in my AUR package) is standalone, specific and isolated from everything else, it was simply deleted in newer versions because of lack of maintenance. What my package does is just adding that little executable and gluing together some additional services/units, in the same way that CUPS adds their own.
 +
 +
::::::::Yes, the services don't have different names, but they don't need it; apart from the identical functionality if you take a look to the dependencies listed in the [https://aur.archlinux.org/packages/sy/systemd-readahead/PKGBUILD  PKGBUILD] you'll see that forbids installing with a systemd older than version 217, so there can't be any conflicts whatsoever, it just brings back that little functionality that was lost and makes it compatible with newer systemd releases without replacing or breaking anything else.
 +
 +
:::::::: To add the cherry on top, not only the services aren't enabled by default, there's a detailed post-install script printing instructions to the user making it harder to shoot into one's foot. I made this package with care, and if any of you had tried before jumping into early conclusions you'd know it.
 +
 +
::::::::I've added a comment in the AUR entry clarifying a bit more in depth all this. Now that everyone is happy, please reject the deletion request and bring back the Readahead section here in the wiki. That's all. --[[User:Swyter|Swyter]] ([[User talk:Swyter|talk]]) 15:42, 8 March 2015 (UTC)

Revision as of 15:42, 8 March 2015

Readahead on AUR

Quoting from a Gentoo developer (https://dev.gentoo.org/~pacho/systemd-readahead.html):

Systemd upstream decided to drop readahead since 217 version [1,2] even if no many alternatives for HDD users apart of migrating to SSD exist [3], because of that, this aims to keep supplying the readahead systemd implementation for now until a better alternative exists.
  1. readahead: wipe out readahead
  2. remove references of readahead
  3. [systemd-devel] [HEADS-UP] Intent to remove readahead from systemd

As usual, if you want to help, provide patches and so feel free to open a bug report to bugs.gentoo.org. The same if you want to report a bug of course ;)

So, please, stop messing around. Until something better appears this is the best alternative around that actually works.

It's not confusing, it was there, made the boot-up faster, was removed and now it can be seamlessly added back, optionally and without fuss.

Where's the problem?

--Swyter (talk) 12:43, 6 March 2015 (UTC)

If this "project" was a fork of systemd-readahead, then it would have provided a modified or at least repackaged sources of the original software, apply patches, bug fixes etc. The package systemd-readaheadAUR in the AUR just builds systemd-216 with everything disabled but readahead, which is conflicting with the very definition of fork. This is what's wrong with your AUR package.
The quoted Gentoo page itself does not provide any link to sources, only encourages to report bugs to bugs.gentoo.org. Surely the patches are not mysteriously applied to the already-released systemd-v16 source tarball. This is what's wrong with the "project".
Also, forks are usually renamed to distinguish itself from the original software and to direct bug reports and complaints to the right place. The name systemd-readahead is still connected to the implementation of readahead that was removed in systemd-v217, which makes it totally bad name for a fork.
Until these problems are addressed, I'm against describing this "project" on ArchWiki. Likewise, there are Trusted Users who are against having systemd-readaheadAUR in the AUR (my previous report was accepted).
-- Lahwaacz (talk) 16:55, 6 March 2015 (UTC)
Sorry, but I don't follow.
There's no rule that enforces having to fork a project to package it. It's been clearly explained in the AUR package description, it just adds back the official readahead implementation. There's packages for other distros, I needed and I ported it to Arch spending my time on it, I wanted to share because it offered the choice of having it back, customization is a cornerstone of the Arch way. How can this confuse users or be misleading? And please, it's just *you* abusing your position and wanting to delete the package, it does no good.
The package is well written and has received four votes already, so people clearly use and like it. Stop antagonizing this project.
The time wasted with this could be used to manage deprecated packages that are truly useless. This is not.
--Swyter (talk) 17:20, 6 March 2015 (UTC)
There's nothing to discuss here, the deletion request was already accepted. One small but important detail is how anyone can file a deletion request, regardless of "position". If either party has further comments, use email. Section removed, closing. -- Alad (talk) 20:01, 6 March 2015 (UTC)
Well, Alad, I think that was too hasty because the second request is still pending... -- Lahwaacz (talk) 22:10, 6 March 2015 (UTC)
So the package was deleted, then uploaded right after? OP: Did you at least contact the TU in question before doing so? :/ -- Alad (talk) 22:32, 6 March 2015 (UTC)
It looked and it still looks like a pretty arbitrary decision to me, he sounds serious/professional but uses a lot of verbal tricks in there, offering references about a previous deletion request made by himself and doing it in third person, and as discussed above the arguments don't hold up, and surely not for a flagrant deletion. I still don't know how to properly reply to an AUR request, I cannot post to the aur-request mailing list. It's not explained anywhere.
Edit: It's pretty clear he just wants that wiki section removed, take a look, didn't even waited for confirmation.
Second edit: About the spurious claims about forkness, well, just open the PKGBUILD and see it by yourself, it actually patches the original sources if that makes it different somehow. This is egregious. --Swyter (talk) 06:46, 7 March 2015 (UTC)
It was me who deleted the section. If a package is deleted from the AUR, related content is deleted from the wiki; an undiscussed reupload is no proper justification to re-add it.
Now if you want to reply to an AUR request, contact the TU who accepted it. His email is linked from the mailing list thread, as well as in Trusted User. Return here after you've done so. -- Alad (talk) 10:48, 7 March 2015 (UTC)
So, I talked with User:Jleclanche yesterday early and after a bit of back and forth we seemed to agree that this was a chain of misunderstandings. First of all, nobody really bothered to test it, blindly trusting each other in the process. Secondly, I'm not forking the whole systemd, you all seemed to think that my package was replacing parts of the monolithic systemd binary with a broken, limited version of it, sort of like a half-assed backport, that is simply not true.
The systemd-readahead binary (which is the only compiled executable in my AUR package) is standalone, specific and isolated from everything else, it was simply deleted in newer versions because of lack of maintenance. What my package does is just adding that little executable and gluing together some additional services/units, in the same way that CUPS adds their own.
Yes, the services don't have different names, but they don't need it; apart from the identical functionality if you take a look to the dependencies listed in the PKGBUILD you'll see that forbids installing with a systemd older than version 217, so there can't be any conflicts whatsoever, it just brings back that little functionality that was lost and makes it compatible with newer systemd releases without replacing or breaking anything else.
To add the cherry on top, not only the services aren't enabled by default, there's a detailed post-install script printing instructions to the user making it harder to shoot into one's foot. I made this package with care, and if any of you had tried before jumping into early conclusions you'd know it.
I've added a comment in the AUR entry clarifying a bit more in depth all this. Now that everyone is happy, please reject the deletion request and bring back the Readahead section here in the wiki. That's all. --Swyter (talk) 15:42, 8 March 2015 (UTC)