Magic suggestions
Posted: Mon Jan 31, 2005 5:29 pm
Errors/nitpicks I discovered in /bin/magic:
1. The use of the -r switch to the rm command when applied to a single file.
2. Line 421 states downloading magic.md5 failed, when patches.md5 failed.
3. I'd like to see cleanup() moved to /etc/functions.magic so it's not duplicated in the patches file.
Errors/nitpicks in current patches file:
1. The (compatibility) code will check for the functions.magic and patches.magic files, and assume they are fine if present. If they are an old version however, the patch wouldn't know since it doesn't perform an md5sum check.
2. Again, the use of the -r switch to the rm command when applied to single files.
3. Should use arguments to functions such as delDatabase, instead of exporting variables.
4. Never, ever, ever change my default editor from nano to vim! Unforgivable! It would be better to check if EDITOR is not present or undefined before making changes. Remember - Gentoo is about choice and a lot of us like to do things our own way. .
5. Gentoox user check assumes that the xbox admin wouldn't ever remove that user manually. It would be good to check /etc/passwd, and perhaps modify the GECOS field for the Gentoox user to say something like "Dependency for magic" so as to alert the unwary.
6. Looks relatively easy to circumvent the 5k/s download limit... probably should make that a server limitation rather than a client limitation (if possible).
7. Line 800 - `chmod 777 /bin/magic` looks... scary. Also similar issue for lines 1877 and 1933.
8. Isn't it possible to install mplayer without X using USE="-X"? Or in this circumstance does magic become irrelevant (since the patch is X-specific)?
Errors/nitpicks in the current xserver.b0x file:
1. Line 84 - chmod removes the suid bit, hence 'startx' fails to work for people who like to disble xdm.
2. Again, I don't like the /etc clutter.
I haven't been completly through the functions.magic file, or most of the b0x
files, so I can't comment on these yet.
Recommendations:
1. Move functions.magic to magic/functions and patches.magic to magic/patches. Also, these likely belong somewhere other than the /etc (configuration) directory since any manual editing will cause md5sum check by /bin/magic to fail and hence changes will be overridden.
2. Ditch the patches file compatibility code - it's probably too much duplication. If people are really running such ancient magic code and finally decide they want to use magic once more, have the old incompatible versions of magic detected and just point them to a URL with instructions on how to 'manually' download and install the new version.
4. Move /etc/gentoox_version to /etc/gentoox-release to be more inline with Gentoo standards.
5. Always ensure the EXTRAVERSION of the kernel Makefile matches the /usr/src/linux-... directory name to move inline with the Gentoo naming convention. The default kernel for 1.5Pro didn't seem to do this.
6. Move /etc/conf.d/oneshotmagicupdate to the same location as the new magic/ folder (mentioned in point 1).
7. Find a way for the admin to ditch the gentoox user - it shouldn't be essential, only optional.
8. You're probably going to seriously hate this suggestion, but the whole time I was reading your scripts I just kept thinking... this really goes against the Gentoo way of doing things. I realize that magic has evolved from copy and paste commands and patches, to b0x patches, to the b0x management system we now have, all probably without specifically being planned. Shallax, you often ask on the Gentoox main page what Gentoox users would like to see, and that's really commendable that you'll change directions with regards to magic if it'll make people happier.
However if I were to try and achieve the same goal that magic has, and I were to start over, I would look into a system that utilizes PORTDIR_OVERLAY more effectively. Perhaps if an official ebuild were broken (and I realize you have little power to fix this nowadays), you could have a tool (which is installed via ebuild, via the PORTDIR_OVERLAY directory) that checks your website for PORTAGE_OVERLAY updates (that are used to replace broken official ebuilds), and a working combination of package masks for files in /etc/portage. This way, users can still very much continue to do things 'the Gentoo way' and have a much clearer understanding of exactly what you intend to do to a Gentoox system without an end user having to read your source code. They may feel they are not in the dark anymore, as I once did.
As a side effect, it might encourage users to submit updates thus lifting the workload from your shoulders. As it stands at the moment, having a patch file run and then subsiquentely deleted requires some investigation for an end user to get ahold of. Correct me if I'm wrong, but it's not available on the website (although the b0x files are).
Looking through the portage.b0x file now, I see work has been started on something like this, but essentially it'd be really sweet to have a magic 'ebuild' that a user can chose to install, rather than have a modded-meta-distro. This would be already installed by default on your Stardust releases so the end user who doesn't care about any of this shouldn't notice much, if anything.
Final comments:
Very nice job. Without Gentoox, I wouldn't have bothered to purchase an Xbox in the first place. It's easy for me to sit back and complain, but you've battled on for longer than I would have bothered, and even maintained more frequent updates that I ever have for my personal projects.
Also, thanks for your recommendation (viewtopic.php?t=2467) of the Xenuim Ice. I can't believe what I was missing out on before.
1. The use of the -r switch to the rm command when applied to a single file.
2. Line 421 states downloading magic.md5 failed, when patches.md5 failed.
3. I'd like to see cleanup() moved to /etc/functions.magic so it's not duplicated in the patches file.
Errors/nitpicks in current patches file:
1. The (compatibility) code will check for the functions.magic and patches.magic files, and assume they are fine if present. If they are an old version however, the patch wouldn't know since it doesn't perform an md5sum check.
2. Again, the use of the -r switch to the rm command when applied to single files.
3. Should use arguments to functions such as delDatabase, instead of exporting variables.
4. Never, ever, ever change my default editor from nano to vim! Unforgivable! It would be better to check if EDITOR is not present or undefined before making changes. Remember - Gentoo is about choice and a lot of us like to do things our own way. .
5. Gentoox user check assumes that the xbox admin wouldn't ever remove that user manually. It would be good to check /etc/passwd, and perhaps modify the GECOS field for the Gentoox user to say something like "Dependency for magic" so as to alert the unwary.
6. Looks relatively easy to circumvent the 5k/s download limit... probably should make that a server limitation rather than a client limitation (if possible).
7. Line 800 - `chmod 777 /bin/magic` looks... scary. Also similar issue for lines 1877 and 1933.
8. Isn't it possible to install mplayer without X using USE="-X"? Or in this circumstance does magic become irrelevant (since the patch is X-specific)?
Errors/nitpicks in the current xserver.b0x file:
1. Line 84 - chmod removes the suid bit, hence 'startx' fails to work for people who like to disble xdm.
2. Again, I don't like the /etc clutter.
I haven't been completly through the functions.magic file, or most of the b0x
files, so I can't comment on these yet.
Recommendations:
1. Move functions.magic to magic/functions and patches.magic to magic/patches. Also, these likely belong somewhere other than the /etc (configuration) directory since any manual editing will cause md5sum check by /bin/magic to fail and hence changes will be overridden.
2. Ditch the patches file compatibility code - it's probably too much duplication. If people are really running such ancient magic code and finally decide they want to use magic once more, have the old incompatible versions of magic detected and just point them to a URL with instructions on how to 'manually' download and install the new version.
4. Move /etc/gentoox_version to /etc/gentoox-release to be more inline with Gentoo standards.
5. Always ensure the EXTRAVERSION of the kernel Makefile matches the /usr/src/linux-... directory name to move inline with the Gentoo naming convention. The default kernel for 1.5Pro didn't seem to do this.
6. Move /etc/conf.d/oneshotmagicupdate to the same location as the new magic/ folder (mentioned in point 1).
7. Find a way for the admin to ditch the gentoox user - it shouldn't be essential, only optional.
8. You're probably going to seriously hate this suggestion, but the whole time I was reading your scripts I just kept thinking... this really goes against the Gentoo way of doing things. I realize that magic has evolved from copy and paste commands and patches, to b0x patches, to the b0x management system we now have, all probably without specifically being planned. Shallax, you often ask on the Gentoox main page what Gentoox users would like to see, and that's really commendable that you'll change directions with regards to magic if it'll make people happier.
However if I were to try and achieve the same goal that magic has, and I were to start over, I would look into a system that utilizes PORTDIR_OVERLAY more effectively. Perhaps if an official ebuild were broken (and I realize you have little power to fix this nowadays), you could have a tool (which is installed via ebuild, via the PORTDIR_OVERLAY directory) that checks your website for PORTAGE_OVERLAY updates (that are used to replace broken official ebuilds), and a working combination of package masks for files in /etc/portage. This way, users can still very much continue to do things 'the Gentoo way' and have a much clearer understanding of exactly what you intend to do to a Gentoox system without an end user having to read your source code. They may feel they are not in the dark anymore, as I once did.
As a side effect, it might encourage users to submit updates thus lifting the workload from your shoulders. As it stands at the moment, having a patch file run and then subsiquentely deleted requires some investigation for an end user to get ahold of. Correct me if I'm wrong, but it's not available on the website (although the b0x files are).
Looking through the portage.b0x file now, I see work has been started on something like this, but essentially it'd be really sweet to have a magic 'ebuild' that a user can chose to install, rather than have a modded-meta-distro. This would be already installed by default on your Stardust releases so the end user who doesn't care about any of this shouldn't notice much, if anything.
Final comments:
Very nice job. Without Gentoox, I wouldn't have bothered to purchase an Xbox in the first place. It's easy for me to sit back and complain, but you've battled on for longer than I would have bothered, and even maintained more frequent updates that I ever have for my personal projects.
Also, thanks for your recommendation (viewtopic.php?t=2467) of the Xenuim Ice. I can't believe what I was missing out on before.