| View previous topic :: View next topic |
| Author |
Message |
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
 Posted: Thu Nov 20, 2014 5:31 pm Post subject: Script to keep your package.* files in order (ala portpeek) |
 |
|
Greetings!
I've been working on a perl script to process and "clean" my package.* files for some time (mostly use it for .keywords and .use). If you're someone like me (pedantic to keep everything sorted, remove any old no longer necessary stuff and a bit lazy to do things manually), you may find this useful.
It does strict checking and matching of the atoms listed against the installed versions (by version, slot, subslot, repository).
It handles globs in category or name pf package.
It joins atoms referring to the same package-version and can optionally process listed keywords, USE flags or /etc/portage/env files, sort them and remove invalid ones. In case you, by mistake, added the same flag for the same package but with opposite sign, it will prompt you to choose which (if any) to keep.
It's kind of similar to portpeek, but adds some features I wanted to have:
- it ignores any entries between matching #IGNORE# lines, so for example I can keep my list of all packages that should be merged with abi_x86_32 flag but are not currently merged (and would otherwise get removed by the script).
- it can ignore a list of USE flags or keywords (to prevent them from being deleted if they're not valid for the installed version matching the atom)
- it can run as batch job, in foreground with only prompt displayed, foreground with full output but no prompts (for piping), etc
It needs File::Temp, File::Find::Rule, and Term::ANSIColor. It was tested with Perl version 5.20.1, but as far as I know, I haven't used any super experimental stuff, so it should be fine with older versions.
I plan to expand it and add more options and I'll be happy to get feedback/bug reports/suggestions 
- If you want to install manually, here's the link to the script: https://github.com/aayla-secura/cleanpkgfile
- There is an ebuild here: you can copy the ebuild to your local repo or you can add the entire overlay with layman:
create a file in /etc/layman/overlays (secura.xml for example) with the following
| Code: | <?xml version="1.0" ?>
<repositories version="1.0">
<repo priority="50" quality="experimental" status="unofficial">
<name>secura</name>
<description>Ebuilds for projects at https://github.com/aayla-secura/</description>
<homepage>https://github.com/aayla-secura/</homepage>
<owner>
<email>aayla.secura.1138@gmail.com</email>
</owner>
<source type="git">git://github.com/aayla-secura/overlay.git</source>
</repo>
</repositories>
|
then | Code: | | layman -f ; layman -a secura |
Last edited by AaylaSecura on Sun Nov 23, 2014 1:20 pm; edited 3 times in total |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Nov 20, 2014 6:45 pm Post subject: |
|
|
| AaylaSecura wrote: | | I've been working on a perl script to process and "clean" my package.* files for some time (mostly use it for .keywords and .use). If you're someone like me (pedantic to keep everything sorted, remove any old no longer necessary stuff and a bit lazy to do things manually), you may find this useful. |
Sounds fun. I've wanted a helper like that for a while that we can call from update. I've been burnt before by perl helpers (autounmask breakage) though in this case it's only ever going to be used after we've done a full update, so it's less of an issue.
Hmm with autounmask the issue wasn't breakage of the tree so much as of the script itself, which didn't get corrected for a while, and led to me reimplementing it in bash. So are you going to keep this thing up to date, and be responsive when it breaks on your users? As otherwise I'll have to redo it, and it'll be a pita, since that kind of thing (as with someone moving on and letting it bitrot for a while) tends to happen at the most inconvenient point. Like I said less of an issue, but a concern nonetheless.
| Quote: | | It's kind of similar to portpeek, but adds some features I wanted to have - it ignores any entries between matching #IGNORE# lines, so for example I can keep my list of all packages that should be merged with abi_x86_32 flag but are not currently merged (and would otherwise get removed by the script). |
I'd rather have a config file where the user can simply tell it what flags to ignore (for precisely this use-case as an example, but not the only one.)
I don't do perl, so can't comment on the script; my advice would be to get feedback from mv, if you can. Hopefully he'll show up soon :-) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Nov 20, 2014 8:08 pm Post subject: |
|
|
| steveL wrote: | | Hopefully he'll show up soon |
If you call the devil... 
Of course, I am always interested in such a script, but I had a reason that I thought several years ago that this is best implemented in eix (first as eix -t and eix -T and then as eix-test-obsolete): Since portage has no clean API for all details, it is not easy to get all data which you need in a compatible way; eix already knows internally all the data which you need...
Comments to the script... well, what can I say? If you write an ebuild for your package, you only need File::Find::Rule and Term::ANSIColor, because all of the rest is in perl since 5.6.1 (perhaps even earlier, but your way of configuring Getopt::Long is only supported since 2.24). Perhaps, it would be a good idea to require 5.006001;
I only skipped over the script itself and have not much comments except for the obvious ones: Where is "use warnings;" and "use strict;"? Do you have a reason to use "our" instead of "my"? And I hope you are aware that usually perl prototypes are bad (but perhaps you have good reasons to use them?)
And something not perl-related: It is a security risk to store predictable filenames in /tmp, so the default is not nice. You could use File::Temp which is in perl also since 5.6.1 |
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Thu Nov 20, 2014 9:37 pm Post subject: |
|
|
| steveL wrote: | | So are you going to keep this thing up to date, and be responsive when it breaks on your users? |
Yes, I plan to. If for some reason I deem this script to be useless and stop working on it, I'll make it clear it's no longer maintained
| steveL wrote: | | I'd rather have a config file where the user can simply tell it what flags to ignore (for precisely this use-case as an example, but not the only one.) |
Good idea, didn't think about it - I will add this functionality soon enough.
| mv wrote: | | Of course, I am always interested in such a script, but I had a reason that I thought several years ago that this is best implemented in eix (first as eix -t and eix -T and then as eix-test-obsolete): Since portage has no clean API for all details, it is not easy to get all data which you need in a compatible way; eix already knows internally all the data which you need... |
My script originally used eix to get the information, but since I could get everything I needed from /var/db/pkg, I decided to use that and not add the dependency on eix.
| mv wrote: | | If you write an ebuild for your package, you only need File::Find::Rule and Term::ANSIColor, because all of the rest is in perl since 5.6.1 (perhaps even earlier, but your way of configuring Getopt::Long is only supported since 2.24). Perhaps, it would be a good idea to require 5.006001; |
Thanks for the tips! I'm not experienced in ebuilds (yet, though I'm working on this now), but I do plan to have a go at writing one for the script soon.
| mv wrote: | | Where is "use warnings;" and "use strict;"? |
I turn on warnings when I test it to see if there's anything important, but since it outputs messages about use of uninitialized variables everytime it loops (and I haven't made it a priority to fix those), I removed warnings when I shared it.
| mv wrote: | | Do you have a reason to use "our" instead of "my"? |
I only used our in the top level, since there it's equivalent to my, is it not? (at least for a single script file that isn't part of anything bigger)
| mv wrote: | | And I hope you are aware that usually perl prototypes are bad (but perhaps you have good reasons to use them?) |
Interesting, I will have a read at that! I thought they'd be good, cause it will make it easier for me to find mistakes I've made - when I decide to rewrite a subroutine and change the type/number of arguments it expects - if that is reflected in the prototype, perl will spit an error if I've forgotten to update the call to the function somewhere else.
| mv wrote: | | And something not perl-related: It is a security risk to store predictable filenames in /tmp, so the default is not nice. You could use File::Temp which is in perl also since 5.6.1 |
I know, but I thought it's pretty safe, since the name contains the time of creation up to the second, so it's unlikely that there is a clash. But I guess you're right, I will change it to use File::Temp
If it's not obvious yet - I am not an expert at Perl (or any programming language yet), so excuse my novice mistakes  Thanks for the help! |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Nov 21, 2014 4:43 am Post subject: |
|
|
| mv wrote: | | Of course, I am always interested in such a script, but I had a reason that I thought several years ago that this is best implemented in eix (first as eix -t and eix -T and then as eix-test-obsolete): Since portage has no clean API for all details, it is not easy to get all data which you need in a compatible way; eix already knows internally all the data which you need... |
Ah I remember the discussion around eix-test-obsolete, but haven't tried it yet.
Don't bother then, AaylaSecura, as there is no way you're going to do better for our uses in update, and likely anybody's, imo.
You'd be much better off making sure mv's eix-test-obsolete is feature-complete with yours, and then helping push it forward on the QA side (bug reports and feedback initially, though it's *gack* C++..)
If you're new to coding, start here. It's a classic of the CS field, and the best introduction I (and others;) have ever read. |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2284
Location: Adendorf, Germany
|
| Posted: Fri Nov 21, 2014 9:11 am Post subject: |
|
|
| AaylaSecura wrote: | | mv wrote: | | Where is "use warnings;" and "use strict;"? |
I turn on warnings when I test it to see if there's anything important, but since it outputs messages about use of uninitialized variables everytime it loops (and I haven't made it a priority to fix those), I removed warnings when I shared it. |
The warning about using an unitialized variable is a big neon light pointing at a possibly huge bug that must be fixed ASAP. Turning of warnings is the wrong way. And normally, those warnings can be fixed in under 30 seconds.
To clarify that: Using an unitialized value means, that something you want your program to do, check or test is not happening at all!
| AaylaSecura wrote: | | mv wrote: | | Do you have a reason to use "our" instead of "my"? |
I only used our in the top level, since there it's equivalent to my, is it not? (at least for a single script file that isn't part of anything bigger) |
Use my. You can use 'our' if you want a global variable be visible and changable in the BEGIN {} sectioon, if you have any. Apart from that you do not need 'our' outside Module development.
| AaylaSecura wrote: | | mv wrote: | | And I hope you are aware that usually perl prototypes are bad (but perhaps you have good reasons to use them?) |
Interesting, I will have a read at that! I thought they'd be good, cause it will make it easier for me to find mistakes I've made - when I decide to rewrite a subroutine and change the type/number of arguments it expects - if that is reflected in the prototype, perl will spit an error if I've forgotten to update the call to the function somewhere else. |
You can add a list of your subs at the top of your file if you like, but you won't need them.
Perl prototypes do _NOT_ do what you think. The only valid reason to use prototypes is to make a subroutine an operator (meaning it can be used is a bigger statement without parenthesis)
| AaylaSecura wrote: | | If it's not obvious yet - I am not an expert at Perl (or any programming language yet), so excuse my novice mistakes Thanks for the help! |
The biggest help you can get is from Perl::Critic. And if you use Eclipse, I recommand the E-P-I-C Perl IDE plugin. It is awesome and does a lot for you like using Module::Starter, Perl::Critic and Perl::Tidy automatically and configurably.
And another link about prototypes:
http://www.perlmonks.org/?node_id=861966
btw: both modernperl and perlmonks are great resources of perl knowledge.
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Nov 21, 2014 12:29 pm Post subject: |
|
|
| steveL wrote: | | eix-test-obsolete is feature-complete |
There is no proper handling of use-flags in eix. Therefore, eix-test-obsolete can do almost nothing concerning package.use except for finding duplicate entries and/or matches for unavailable and/or uninstalled packages/versions; the actual use-flags are not considered. |
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Fri Nov 21, 2014 3:48 pm Post subject: |
|
|
| steveL wrote: | Ah I remember the discussion around eix-test-obsolete, but haven't tried it yet.
Don't bother then, AaylaSecura, as there is no way you're going to do better for our uses in update, and likely anybody's, imo.
You'd be much better off making sure mv's eix-test-obsolete is feature-complete with yours, and then helping push it forward on the QA side (bug reports and feedback initially, though it's *gack* C++..)
If you're new to coding, start here. It's a classic of the CS field, and the best introduction I (and others;) have ever read. |
I had a more thorough read of the man page part about eix-test-obsolete and while it does offer an interface to portage's internals, I think it's not as convenient as I'd like it to be - having to set lots of variables to control what it does and which files it processes; also, it does not offer the functionality to modify/correct the file being examined, prompt the user for action, ignore entries/use flags - the kind of things I'm trying to implement. I could write a bash script to act as a wrapper for eix (set all the variables needed based on options passed to it on the command line and thus be an easy interface to it), but I still believe an independent script accessing information about portage straight from the database offers more flexibility.
And thanks for the link, I'll have a read!
Thank you, mv, for the explanations - I will go over my script and try to improve the code based on your comments! |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Nov 21, 2014 5:33 pm Post subject: |
|
|
| mv wrote: | | There is no proper handling of use-flags in eix. Therefore, eix-test-obsolete can do almost nothing concerning package.use except for finding duplicate entries and/or matches for unavailable and/or uninstalled packages/versions; the actual use-flags are not considered. |
| Quote: | | I had a more thorough read of the man page part about eix-test-obsolete and while it does offer an interface to portage's internals, I think it's not as convenient as I'd like it to be - having to set lots of variables to control what it does and which files it processes; also, it does not offer the functionality to modify/correct the file being examined, prompt the user for action, ignore entries/use flags - the kind of things I'm trying to implement. |
KK ;) Just wanted to be sure there's no dupe going on, since we rely on eix already.
I highly recommend IRC: chat.freenode.net btw, if you're not already online; #gentoo and #gentoo-chat ofc, but there are channels on every programming language out there, including #awk and #perl as well as #gentoo-perl and #gentoo-dev-help for ebuild help.
We hang out in #friendly-coders which was started by a few of us from #gentoo-chat, so feel free to drop by :-)
I'll take a look at integrating the script into update, and feedback in a week or so.
Regards,
igli |
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Sat Nov 22, 2014 11:45 am Post subject: |
|
|
| steveL wrote: | I highly recommend IRC: chat.freenode.net btw, if you're not already online; #gentoo and #gentoo-chat ofc, but there are channels on every programming language out there, including #awk and #perl as well as #gentoo-perl and #gentoo-dev-help for ebuild help.
We hang out in #friendly-coders which was started by a few of us from #gentoo-chat, so feel free to drop by
I'll take a look at integrating the script into update, and feedback in a week or so.
|
Will do so
Ok, so I fixed all the warnings (most of them were coming from optional arguments to subroutines, which I hadn't initialized with a default value in case they weren't specified) and changed to lexical variables.
Also, it now uses File::Temp for a more secure tmp file naming.
I read about prototypes and I believe I understand what their use is, so I removed them (from all but one subroutine, which I believe is better implemented this way)
I added the option to ignore a list of specified USE flags/keywords as steveL suggested.
I also added the option not to remove entries with no installed versions
Next, I will add some more options to control which checks and actions are to be skipped and also an ability to diff the original and tmp file before the user is prompt for overwrite.
I will also have a go at writing an ebuild. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Nov 22, 2014 3:27 pm Post subject: |
|
|
| AaylaSecura wrote: | Ok, so I fixed all the warnings (most of them were coming from optional arguments to subroutines, which I hadn't initialized with a default value in case they weren't specified) and changed to lexical variables.
Also, it now uses File::Temp for a more secure tmp file naming.
I read about prototypes and I believe I understand what their use is, so I removed them (from all but one subroutine, which I believe is better implemented this way) |
Good good.
| Quote: | I added the option to ignore a list of specified USE flags/keywords as steveL suggested.
I also added the option not to remove entries with no installed versions |
woot thanks :-)
| Quote: | | Next, I will add some more options to control which checks and actions are to be skipped and also an ability to diff the original and tmp file before the user is prompt for overwrite. |
We don't need that in update, if you're looking at this from the pov of being a utility which other utilities call, as we already have the facilities for colourised diffs when editing package.use, for example, which ties into our tempfiles setup.
From our perspective, if we can integrate so that the process separation is maintained, it means the calling app can display in whatever manner it chooses, including in a GUI toolkit, for example (which doesn't apply to update, but might apply to other potential users.)
What would be good is to have a --write option to confirm the overwrite on the second call (or even a separate script if you prefer, since it would have so much less to do) if you're going to backup files at your side. Or a calling app would backup the files or directories concerned (if needed: the user might be using git, for example, and have told us not to backup, to save on file writes) as update currently does for things it edits. Then display the diff in whatever UI format it wants, and get confirmation from the user, if need be, before confirming the write, or simply continuing in the latter case.
Sometimes we'll be running in script mode and will want the cleanup and write to just happen on the first call.
Not to say you don't want to do other things; just letting you know what script-writers calling it are going to be after.
| Quote: | | I will also have a go at writing an ebuild. |
Please do.
In case it helps, I posted my first ebuild here as an example of how to a vcs snapshot build, ie not live but derived from a vcs, back in the days when eclasses were a lot less sophisticated. Feedback (including criticism) welcome :-) |
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Sat Nov 22, 2014 8:00 pm Post subject: |
|
|
| steveL wrote: | | What would be good is to have a --write option to confirm the overwrite on the second call |
Done! I added several options to control the amount of output on the console, what to prompt for and whether or not to backup:
force-overwrite, quiet, batch, backup
I think different combinations of them can do pretty much everything - it can run in background (no prompts), foreground with only prompt displayed, foreground with full output but no prompt (for piping), etc.
Thanks for the link, I wrote an ebuild and installed it on my system. I used the ebuild for perl-cleaner as an example on how to use a git repo as source.
I only listed ~amd64 keywords, since I can only test it on amd64, whoever tests it on other arches can let me know how they get along.
I wasn't sure which version of perl to depend on, so I simply wrote >5. Any criticism/feedback on the ebuild are welcome! |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Nov 23, 2014 8:19 am Post subject: |
|
|
| AaylaSecura wrote: | | I wasn't sure which version of perl to depend on, so I simply wrote >5 |
You need at least 5.6.1 (or must list further virtual/...).
If you depend on >=dev-lang/perl-5.6.1 you can also remove the other two virtual/... entries since some versions of these packages are shipped with perl-5.6.1.
I found this out with e.g. | Code: | | corelist -a /Term::ANSIColor/ |
Two other independent remarks:
It might make sense to tag releases of cleanpkg with git: This way people can download the tarball with github without needing a live ebuild.
It might make sense to make a separate repository for your overlay; this way people can just update your overlay (e.g. after adding it to layman) and get informed when you released a new version (you can just bump the version in your overlay whenever you make a new tag for cleanpkg).
For an example, you can check out the mv overlay (consider e.g. dev-util/mv_perl or app-shells/zsh-syntax-highlighting for an example how only a released or a released and simultaneously a live-version is supported; however, if you release sufficiently often - releasing costs nothing - you do not need a live version at all since you are your own upstream and know exactly when to bump the ebuild...). In the example dev-util/mv_perl you also see in the comments in RDEPEND why the virtuals are omitted...
(Currently I cannot give you a more detailed address since the server with the mv overlay appears to be down; I hope that it will be back in some hours). |
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Sun Nov 23, 2014 1:16 pm Post subject: |
|
|
| mv wrote: | You need at least 5.6.1 (or must list further virtual/...).
If you depend on >=dev-lang/perl-5.6.1 you can also remove the other two virtual/... entries since some versions of these packages are shipped with perl-5.6.1.
I found this out with e.g. | Code: | | corelist -a /Term::ANSIColor/ |
|
Doh, I missed you mentioned that in your first post, sorry!
| mv wrote: |
It might make sense to tag releases of cleanpkg with git: This way people can download the tarball with github without needing a live ebuild.
It might make sense to make a separate repository for your overlay; this way people can just update your overlay (e.g. after adding it to layman) and get informed when you released a new version (you can just bump the version in your overlay whenever you make a new tag for cleanpkg).
|
Done! I added a repo for an entire overlay, added a tag for the first release and updated the ebuild to use the tag - tested and works |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Nov 23, 2014 1:41 pm Post subject: |
|
|
| AaylaSecura wrote: | Done! I added several options to control the amount of output on the console, what to prompt for and whether or not to backup:
force-overwrite, quiet, batch, backup
I think different combinations of them can do pretty much everything - it can run in background (no prompts), foreground with only prompt displayed, foreground with full output but no prompt (for piping), etc. |
Excellent :-) I won't be able to put code-time into integrating it for a few days, as I'm just coming to the end of a load of work, and will likely crash and take headtime for a couple of days after that, so give me a week or so to feedback about how it turns out.
| Quote: | Thanks for the link, I wrote an ebuild and installed it on my system. I used the ebuild for perl-cleaner as an example on how to use a git repo as source.
I only listed ~amd64 keywords, since I can only test it on amd64, whoever tests it on other arches can let me know how they get along.
I wasn't sure which version of perl to depend on, so I simply wrote >5. Any criticism/feedback on the ebuild are welcome! |
Only thing I'd say is that you shouldn't version a live build like that (cleanpkgfile-0.1_alpha.ebuild). Give it a version of 99999, so it'd be: cleanpkgfile-99999.ebuild
4 9's is conventional, but 5 allows you to be sure it's never going to get considered less than a normal ebuild (if we use dates for snapshots.) Portage used to have a "cvs-" version prefix which could have been changed to "vcs-" very easily (and given the semantic people wanted to attach to a new suffix, that would have required much more work across the ecosystem) but as things stand, we have to stick with a kludge. Still it works fine for the simple case of one repo/live-build, and versioned tags. |
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Sun Nov 23, 2014 1:46 pm Post subject: |
|
|
| steveL wrote: | | Only thing I'd say is that you shouldn't version a live build like that (cleanpkgfile-0.1_alpha.ebuild). Give it a version of 99999, so it'd be: cleanpkgfile-99999.ebuild |
Hmm, I was under the impression that live ebuilds are those that use the latest sources (the HEAD of my master branch in this case); since I just added a tag named 0.1_alpha and made the ebuild use that commit ID as the source, isn't that not a live ebuild anymore?
EDIT: I grep'ed the ebuilds in the portage tree and they seem to follow this convention as I thought - those with versions 9999 are the ones that close the master branch and those that use a specific branch/tag have normal version numbers |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Nov 23, 2014 2:11 pm Post subject: |
|
|
Oh my bad I thought the the ebuild itself didn't have any sort of snapshot info (EGIT_COMMIT) but it does.
My bad, tired. Apologies.
Might want to stick a 99999 one in there then (same thing, just no EGIT_COMMIT) for people to test the latest snapshot. You'll find that useful if you continue to maintain this, as a way of pushing bugfixes immediately, which is much better for those users who make the effort to get in touch with you (eg on IRC.) And ofc on your side, it means you get immediate acceptance-testing. |
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Mon Nov 24, 2014 11:56 am Post subject: |
|
|
| steveL wrote: | Oh my bad I thought the the ebuild itself didn't have any sort of snapshot info (EGIT_COMMIT) but it does.
My bad, tired. Apologies.
Might want to stick a 99999 one in there then (same thing, just no EGIT_COMMIT) for people to test the latest snapshot. You'll find that useful if you continue to maintain this, as a way of pushing bugfixes immediately, which is much better for those users who make the effort to get in touch with you (eg on IRC.) And ofc on your side, it means you get immediate acceptance-testing. |
Yup, I did add a live one as well
Also, I discovered that using the git-r3 eclass (needed for EGIT_COMMIT) makes portage detect this ebuild as a live ebuild (the live-rebuild portage set only check the inheritance). To prevent that from happening the static ebuild now uses SRC_URI pointing to a .tar.gz file in the archives of github. (Don't know if there's another/better way to point to a specific tag on github) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Nov 24, 2014 5:43 pm Post subject: |
|
|
| AaylaSecura wrote: | | To prevent that from happening the static ebuild now uses SRC_URI pointing to a .tar.gz file in the archives of github. |
That's the way it should be for non-live ebuilds: This way the user does not need a copy of the git repository but only that tarball, and he has a checksum in Manifest.
The "inherit git-..." is needed only for "true" live ebuilds.
It is admissible to make some inherit's (like inherit git-...) conditional depending on ${PV} so that you can use the same code for the live ebuild as for the non-live ebuild. Whether you do this is a matter of taste: It makes the ebuild less readable, but you have the same file for both versions.
Another two remarks - Gentoo developers have agreed to install small files like zsh-completion unconditionally without any USE-Flag (people who do not want these files are supposed to use INSTALL_MASK).
- The dependency on zsh and gentoo-zsh-completions is bad, since of course the package will run without any problems if you have no zsh installed: some feature is not used, but the package will work, so it is not a required dependency.
|
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Mon Nov 24, 2014 6:19 pm Post subject: |
|
|
| mv wrote: | | This way the user does not need a copy of the git repository but only that tarball, and he has a checksum in Manifest. |
I didn't think about that...
| mv wrote: | | It is admissible to make some inherit's (like inherit git-...) conditional depending on ${PV} so that you can use the same code for the live ebuild as for the non-live ebuild. Whether you do this is a matter of taste: It makes the ebuild less readable, but you have the same file for both versions. |
Thanks for the tip!
| mv wrote: | | Gentoo developers have agreed to install small files like zsh-completion unconditionally without any USE-Flag (people who do not want these files are supposed to use INSTALL_MASK). |
Hmmm, I didn't know that... Now I wonder two things:
Does INSTALL_MASK work with full paths (relative to the installed image) (hence the user can simply exclude "usr/share/zsh/*") or else would they have to use "_*"?
What is the point of the zsh-completion USE then?
| mv wrote: | | The dependency on zsh and gentoo-zsh-completions is bad, since of course the package will run without any problems if you have no zsh installed: some feature is not used, but the package will work, so it is not a required dependency.[/list] |
If the user does not have zsh installed (and hence doesn't have /usr/share/zsh folder) and the ebuild tries to install there - would this folder and its children be created even if I haven't explicitly created them in the ebuild, or would the file be skipped during the copying into the live system? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Nov 24, 2014 6:41 pm Post subject: |
|
|
| AaylaSecura wrote: | | Does INSTALL_MASK work with full paths (relative to the installed image) |
It even works for the directory: The user just adds e.g. /usr/share/zsh or /usr/share/zsh/site-functions
| Quote: | | What is the point of the zsh-completion USE then? |
Some old packages have not yet been updated. For instance, some old versions of eix still use USE=zsh-completion, newer don't.
Moreover, if creating the file has some serious dependencies (e.g. if you need zsh to create the completion file), it might make sense to make this (build-time) dependency optional.
| Quote: | | would this folder and its children be created |
Yes: "insinto ..." creates all parent directories. |
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Mon Nov 24, 2014 6:51 pm Post subject: |
|
|
Oh, ok, thanks for the explanation! I guess since my completion function relies on gentoo-zsh-completions, I either need to notify the user using elog in pkg_postinstall in case they use zsh, or make my function detect whether the needed file is present and only use it if it is (otherwise zsh complains during completion) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Nov 24, 2014 7:23 pm Post subject: |
|
|
| AaylaSecura wrote: | | since my completion function relies on gentoo-zsh-completions |
I did not know this. In this case perhaps the dependency makes sense and it might be useful to keep the USE-flag (for installation of the file and for the gentoo-zsh-completions dependency).
Alternatively, you can use
| Code: | inherit eutils
...
pkg_postinst() {
optfeature "working zsh-completion" "app-shells/gentoo-zsh-completions"
} |
which is better than elog, since it is conditional. However, I think I would suggest to keep the USE-flag in this case, since it is not just needed to install a small file (as I thought by mistake). |
|
| Back to top |
|
|
AaylaSecura
Tux's lil' helper
Joined: 09 Jun 2011
Posts: 122
|
| Posted: Mon Nov 24, 2014 8:33 pm Post subject: |
|
|
Ah, ok, now it makes more sense
| mv wrote: |
| Code: | inherit eutils
...
pkg_postinst() {
optfeature "working zsh-completion" "app-shells/gentoo-zsh-completions"
} |
|
Nice, I did not know about this function - I'll have a read around the eclass manpages for more such gems. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
