It would be nice if repoman had a special parameter (say -b or whatever) to perform a "fake" ebuild $foo install operation and report all the QA problems it can find. portage already has the functionality in place to report quite a few QA problems when a package is merged, such as missing CC, CFLAGS, TEXTRELS, LDFLAGS, etc so why not embedded this functionality to repoman in order to catch such failure before committing the ebuild? Another enhancement would be to make repoman build your package using different/all possible use flags combinations. Of course, these options must not be enabled by default but they should be available to allow devs perform extensive testing without having to develop their own tools for that. Another feature request I would like to propose it to *NEVER* allow repoman to commit changes in stable ebuilds if one of the following parameters have changed: 1) IUSE 2) files in files/ directory because that would change the runtime behavior of stable package and no arch team was involved to test the new changes.
(In reply to comment #0) > portage already has the functionality in place to > report quite a few QA problems when a package is merged, such as missing CC, > CFLAGS, TEXTRELS, LDFLAGS, etc so why not embedded this functionality to > repoman in order to catch such failure before committing the ebuild? Usually I'm compiling on the machine A and committing from the machine B. How repoman should be able to detect LDFLAGS/TEXTREL and so on? > Another enhancement would be to make repoman build your package using different/all possible use flags combinations. This is not a repoman task. There is tatt if you want to do it.
(In reply to comment #1) > (In reply to comment #0) > > portage already has the functionality in place to > > report quite a few QA problems when a package is merged, such as missing CC, > > CFLAGS, TEXTRELS, LDFLAGS, etc so why not embedded this functionality to > > repoman in order to catch such failure before committing the ebuild? > > Usually I'm compiling on the machine A and committing from the machine B. > How repoman should be able to detect LDFLAGS/TEXTREL and so on? > What's the problem here? Make repoman set some good default CFLAGS, LDFLAGS etc and do the compilation and installation on a tmp directory (like ebuild $foo install does) > > > Another enhancement would be to make repoman build your package using different/all possible use flags combinations. > > This is not a repoman task. There is tatt if you want to do it. No I don't. It is a 9999 ebuild. I'd rather have the functionality in repoman so I can detect as many problems as possible before committing.
(In reply to comment #2) > What's the problem here? Make repoman set some good default CFLAGS, LDFLAGS > etc and do the compilation and installation on a tmp directory (like ebuild > $foo install does) You didn't answer to my question. I'm just saying that is impossible do it when I'm keywording _for_ amd64 _from_ a ppc. > No I don't. It is a 9999 ebuild. I'd rather have the functionality in > repoman so I can detect as many problems as possible before committing. Again, repoman is not suppose to compile/install to find the issues.
(In reply to comment #3) > (In reply to comment #2) > > What's the problem here? Make repoman set some good default CFLAGS, LDFLAGS > > etc and do the compilation and installation on a tmp directory (like ebuild > > $foo install does) > > You didn't answer to my question. I'm just saying that is impossible do it > when I'm keywording _for_ amd64 _from_ a ppc. And I said the flag would be optional. If it works for you then use it. Otherwise don't. I never said to make the QA check mandatory. > > > No I don't. It is a 9999 ebuild. I'd rather have the functionality in > > repoman so I can detect as many problems as possible before committing. > > Again, repoman is not suppose to compile/install to find the issues. Says who?
(In reply to comment #4) > And I said the flag would be optional. If it works for you then use it. > Otherwise don't. I never said to make the QA check mandatory. I didn't see the optional word in the previous comment. Ok, probably there was a misunderstanding between what you proposed and what I understand. To check for CC/CFLAGS/LDFLAGS respect you need to compile the package, so repoman should compile the package before do the commit? for example if I should do it for libreoffice my commit could keep 8/9 hours? Do the test manually and don't close for the fun the bug that people open is enough I guess.
(In reply to comment #5) > (In reply to comment #4) > > And I said the flag would be optional. If it works for you then use it. > > Otherwise don't. I never said to make the QA check mandatory. > > I didn't see the optional word in the previous comment. > > Ok, probably there was a misunderstanding between what you proposed and what > I understand. To check for CC/CFLAGS/LDFLAGS respect you need to compile the > package, so repoman should compile the package before do the commit? for > example if I should do it for libreoffice my commit could keep 8/9 hours? I will try one more time to explain. It is ***optional***. If you don't want to use it then do not. Simple as that. I won't reply again to the same thing. > > Do the test manually and don't close for the fun the bug that people open is > enough I guess. I know how to test packages, I've been here long enough. I want a simple test functionality embedded in repoman so I don't have to copy random scripts on every single testing box I own. Again, *sigh*, it is optional.
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
