Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-mathematics/axiom: ChangeLog axiom-200805.ebuild
Donnie Berkholz [EMAIL PROTECTED] writes: On 14:37 Sat 12 Jul , Markus Dittrich (markusle) wrote: 1.1 sci-mathematics/axiom/axiom-200805.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-mathematics/axiom/axiom-200805.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-mathematics/axiom/axiom-200805.ebuild?rev=1.1content-type=text/plain Hi Donnie, Thank you very much for the suggested improvements and they are in place now. Best, Markus -- -- Markus Dittrich (markusle) Gentoo Linux Developer Scientific applications -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Marius Mauch wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' Benefits: - simplified depstrings for most packages (I assume 90% of the tree) - easier maintenance if dependencies are changing, or additional implementations become supported (this could also be achieved with virtuals though) - potentially more accurate dependencies, as some common errors would be eliminated (e.g. proper treatment of use-conditionals, not adding unpack deps to RDEPEND) - long-term adds the possibility to remove bzip2, gzip and tar from @system Potential problems: - might cause trouble for some packages that use custom code for unpacking, or due to circular deps, this could simply be solved with a new RESTRICT value though. - automagic deps could be confusing to devs/users - not available for existing EAPIs (due to the mentioned problems) - slightly slower dep calculations due to the extra processing - possible match errors So, is this something ebuild maintainers would like in general, or does such a feature cause you nightmares? Marius I'm in favor of this. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
Ciaran McCreesh kirjoitti: On Sun, 13 Jul 2008 16:16:23 -0700 Alec Warner [EMAIL PROTECTED] wrote: As far as could be determined by the members at the meeting there no compelling examples in Gentoo who to change or add global scope functions in future EAPIs. As such those problems as stated are not in scope for Gentoo because Gentoo is not attempting to do those things at this time. You mean you don't want per-category/package eclasses, or eclasses that can indicate that they only work with some EAPIs, or eclasses that can indicate that they're being used incorrectly, or the death of EXPORT_FUNCTIONS? All of these have been discussed as desirable future extensions. Yes I can think a lot of features like this that would be of great use in the main tree but as long as Portage is the only official and stable package manager and doesn't support the things you listed, the GLEP is not of much use. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Tue, 15 Jul 2008 18:58:01 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Yes I can think a lot of features like this that would be of great use in the main tree but as long as Portage is the only official and stable package manager and doesn't support the things you listed, the GLEP is not of much use. So you're saying the GLEP's of no use until Portage supports them, but Portage can't support them until you say yes to the GLEP... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Marius Mauch kirjoitti: So, is this something ebuild maintainers would like in general, or does such a feature cause you nightmares? I have actually been thinking about writing support for this into the Java eclasses because most Java upstreams use .zip files and we need app-arch/unzip in DEPEND for that. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
Ciaran McCreesh kirjoitti: On Tue, 15 Jul 2008 18:58:01 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Yes I can think a lot of features like this that would be of great use in the main tree but as long as Portage is the only official and stable package manager and doesn't support the things you listed, the GLEP is not of much use. So you're saying the GLEP's of no use until Portage supports them, but Portage can't support them until you say yes to the GLEP... I am saying that it makes sense to approve both at the same time or have other official package managers approved before accepting the GLEP. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Tue, 15 Jul 2008 19:16:42 +0300 Petteri Räty [EMAIL PROTECTED] wrote: So you're saying the GLEP's of no use until Portage supports them, but Portage can't support them until you say yes to the GLEP... I am saying that it makes sense to approve both at the same time or have other official package managers approved before accepting the GLEP. Why? We know it's a not-too-distant future need. Might as well get it out of the way now so there isn't more than an hour's worth of stuff all needing to be approved at the same time. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: auto-detection of unpack dependencies
Marius Mauch wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' Benefits: - simplified depstrings for most packages (I assume 90% of the tree) - easier maintenance if dependencies are changing, or additional implementations become supported (this could also be achieved with virtuals though) - potentially more accurate dependencies, as some common errors would be eliminated (e.g. proper treatment of use-conditionals, not adding unpack deps to RDEPEND) - long-term adds the possibility to remove bzip2, gzip and tar from @system Potential problems: - might cause trouble for some packages that use custom code for unpacking, or due to circular deps, this could simply be solved with a new RESTRICT value though. - automagic deps could be confusing to devs/users - not available for existing EAPIs (due to the mentioned problems) - slightly slower dep calculations due to the extra processing - possible match errors So, is this something ebuild maintainers would like in general, or does such a feature cause you nightmares? Yes. I think that's something which should be done manually. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Marius Mauch wrote: Potential problems: - might cause trouble for some packages that use custom code for unpacking, or due to circular deps, this could simply be solved with a new RESTRICT value though. As long as this is done to allow a 100% manual override, then this is a _very_ good idea. Rémi -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
Petteri Räty wrote: I am saying that it makes sense to approve both at the same time or have other official package managers approved before accepting the GLEP. In addition, I'd want to see why the particular approach suggested in this GELP is the only way (as some seem to claim). I have yet to be convinced of this, and as I've pointed out before (and do not wish to belabor further here), I believe there are major drawbacks to putting the EAPI in the filename/extension. Rushing to approve this GLEP would be a mistake, IMHO. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
Petteri Räty wrote: Ciaran McCreesh kirjoitti: So you're saying the GLEP's of no use until Portage supports them, but Portage can't support them until you say yes to the GLEP... I am saying that it makes sense to approve both at the same time or have other official package managers approved before accepting the GLEP. I'm not sure that implementation of new features in portage or official status for other package managers needs to be a condition for acceptance of this GLEP. The council's main concern was that there wasn't a clearly defined immediate need for the GLEP so it was sensible to defer it. That isn't an unreasonable suggestion. Would it be more constructive to create a list of new features/capabilities that depend on this GLEP. For each I'd define: 1. The feature/unmet need. 2. Why it can't be done or can only be done poorly without the new GLEP. 3. When we're likely to see the feature become available assuming the GLEP were approved. 4. What package managers are likely to implement it. (Ie their maintainers endorse the need. It sounds like this list might already have some items on it - so why not document them? If the council wants to avoid approving the GLSA for a merely theoretical need they might offer to endorse the idea but delay it pending the implementation of one or more of the new features in one, two, or all three major package managers, or pending support by portage. That would give developers some assurance that they wouldn't waste time going down a road only to be shot down later. It is good for the well-being of Gentoo that the council be relatively conservative with regard to potentially-disruptive decisions. They simply want to see that the benefits outweigh the costs. So, just show them the benefits. At some point the case for going forward outweighs the reluctance to do so. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On 15-07-2008 19:53:47 +0200, Rémi Cardona wrote: Marius Mauch wrote: Potential problems: - might cause trouble for some packages that use custom code for unpacking, or due to circular deps, this could simply be solved with a new RESTRICT value though. As long as this is done to allow a 100% manual override, then this is a _very_ good idea. Manual override as in emerge --nodeps or something. I have no examples at hand, but during bootstrapping I have more than often a problem with dependencies, which requires careful manual emerging of packages (often ignoring deps) because those deps cannot be compiled or emerged yet. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Tue, 15 Jul 2008 13:58:36 -0400 Richard Freeman [EMAIL PROTECTED] wrote: Would it be more constructive to create a list of new features/capabilities that depend on this GLEP. For each I'd define: 1. The feature/unmet need. 2. Why it can't be done or can only be done poorly without the new GLEP. 3. When we're likely to see the feature become available assuming the GLEP were approved. 4. What package managers are likely to implement it. (Ie their maintainers endorse the need. It sounds like this list might already have some items on it - so why not document them? The GLEP already documents what needs it, in the broadest reasonable terms. The problem with specifics is that everyone will then start arguing about how exactly, say, per-cat/pkg eclasses would work, which is irrelevant to the GLEP. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: auto-detection of unpack dependencies
On 2008-07-15 21:40, Tiziano Müller uttered these thoughts: Marius Mauch wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' [snip] So, is this something ebuild maintainers would like in general, or does such a feature cause you nightmares? Yes. I think that's something which should be done manually. Indeed, the correct solution would be to state the deps manually in each ebuild that requires the dep. But in this case it would mean adjusting the DEPEND string of pretty much the entire tree. Until such measures are stated required, this would be a good middle ground, no? The same thing would apply to gcc if all real depends were to be required in all ebuilds, but that would pretty much have to be manually stated since the PM wouldn't be able to judge that by automatic measures. This, on the other hand, can (at least partially) be handled automatically for the ebuild-devs on the PM side of things. Patrick B -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgp6ynNOqGBSu.pgp Description: PGP signature
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 04:14:18 +0200 Marius Mauch [EMAIL PROTECTED] wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' Could do it just as an eclass... inherit work-out-my-unpack-deps-for-me In principle, there's nothing that can't be done on the ebuild side here. For the future EAPI side, you could require package managers to define super-magic/package-manager-unpack-bzip2 etc for whatever they use to do the unpacking, and to make it work with existing EAPIs, use || deps with what existing package managers happen to use as the second item. For current EAPIs it's no worse than the existing situation, where ebuilds have to guess that package managers use 'app-arch/unzip' to unpack zip files. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Fabian Groffen wrote:
Manual override as in emerge --nodeps or something.
No, manual override as in the ebuild turns off auto-detection and
specifically asks for app-arch/{bzip2,gzip,tar,whatever} using DEPEND
Cheers,
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Ciaran McCreesh wrote: On Tue, 15 Jul 2008 04:14:18 +0200 Marius Mauch [EMAIL PROTECTED] wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' Could do it just as an eclass... inherit work-out-my-unpack-deps-for-me In principle, there's nothing that can't be done on the ebuild side here. For the future EAPI side, you could require package managers to define super-magic/package-manager-unpack-bzip2 etc for whatever they use to do the unpacking, and to make it work with existing EAPIs, use || deps with what existing package managers happen to use as the second item. For current EAPIs it's no worse than the existing situation, where ebuilds have to guess that package managers use 'app-arch/unzip' to unpack zip files. This is pretty close to what I had brought up in #gentoo-portage yesterday as well and seems like the best step forward. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Council meeting summary for 10 July 2008
Donnie Berkholz wrote: Hi all, Here is the summary from Thursday's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. wrt GLEP 56: i) I don't see a specification when use.local.desc is finally going to be dropped ii) Why not switch to XML for use.desc as well? (just to be consequent) We could then use XInclude in a package's metadata.xml to include a global use.desc.xml in use.../use (The requirements could then be changed to: the USE flags description has to be written in the packages metadata.xml) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Council meeting summary for 10 July 2008
Tiziano Müller wrote: Donnie Berkholz wrote: Hi all, Here is the summary from Thursday's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. wrt GLEP 56: i) I don't see a specification when use.local.desc is finally going to be dropped ii) Why not switch to XML for use.desc as well? (just to be consequent) We could then use XInclude in a package's metadata.xml to include a global use.desc.xml in use.../use (The requirements could then be changed to: the USE flags description has to be written in the packages metadata.xml) Incremental steps are better then one huge sweeping change. It'll allow us to evaluate the needs and goals of the project as we move forward. The big concern with dropping use.desc is that multiple USE flags that do the same thing will start to pop up across the whole tree because developers won't know that a USE flag already exists for feature X. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 22:15:16 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Could do it just as an eclass... inherit work-out-my-unpack-deps-for-me In principle, there's nothing that can't be done on the ebuild side here. Wouldn't this also require having a variable like SRC_URI or AUTODEP_SRC_URI above inherit? Yep. Although, you could do something like: inherit normal-eclass-stuff SRC_URI=blah inherit fancy-extra-eclass-stuff -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: auto-detection of unpack dependencies
\On 20:10 Tue 15 Jul , Patrick Börjesson wrote: On 2008-07-15 21:40, Tiziano Müller uttered these thoughts: Yes. I think that's something which should be done manually. Indeed, the correct solution would be to state the deps manually in each ebuild that requires the dep. But in this case it would mean adjusting the DEPEND string of pretty much the entire tree. Until such measures are stated required, this would be a good middle ground, no? Could someone explain why manually doing work is better than automatically detecting the deps? This sounds like an argument against automation, and I'm not following it. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpAvCXWU63o1.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 12:23:08 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Could someone explain why manually doing work is better than automatically detecting the deps? This sounds like an argument against automation, and I'm not following it. Sometimes the magic will be wrong. For example, packages that have a .zip file in SRC_URI but that don't unpack that file (say, if they install it into sharedir as-is instead) don't need a dep upon unzip. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] LDFLAGS=-Wl,--hash-style=gnu
all, I'm at the point that -Wl,-O1 appears to be successful. It's time to toss on -Wl,--hash-style=gnu. The issue is that we need glibc 2.5 or higher and not mips. So one solution is to put the following: default/linux: LDFLAGS=-Wl,-O1,--hash-style=gnu default/linux/mips: LDFLAGS=-Wl,-O1 However, this means we'll have to put a has_version check in profile.bashrc of default/linux, which seems a bit cludgy.. Any suggestions? Comments? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] LDFLAGS=-Wl,--hash-style=gnu
On 15-07-2008 15:32:32 -0400, Doug Goldstein wrote: all, I'm at the point that -Wl,-O1 appears to be successful. It's time to toss on -Wl,--hash-style=gnu. The issue is that we need glibc 2.5 or higher and not mips. So one solution is to put the following: default/linux: LDFLAGS=-Wl,-O1,--hash-style=gnu default/linux/mips: LDFLAGS=-Wl,-O1 However, this means we'll have to put a has_version check in profile.bashrc of default/linux, which seems a bit cludgy.. Any suggestions? Comments? I'm just wondering... unless it has changed since last time I installed Gentoo Linux, but isn't the installation manual on purpose conservative with CFLAGS? make.conf.example also does not much more than -march -O2 -pipe. -O1 to the linker feels conservative to me. Still, do we really need to go any further? Why not make additional pointers to possible values for LDFLAGS like we do for C(XX)FLAGS in the installation manual? -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: auto-detection of unpack dependencies
On 20:25 Tue 15 Jul , Ciaran McCreesh wrote: On Tue, 15 Jul 2008 12:23:08 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Could someone explain why manually doing work is better than automatically detecting the deps? This sounds like an argument against automation, and I'm not following it. Sometimes the magic will be wrong. For example, packages that have a .zip file in SRC_URI but that don't unpack that file (say, if they install it into sharedir as-is instead) don't need a dep upon unzip. Indeed, that is a great argument for the RESTRICT. I wonder how many packages do this? To get a quick idea, I did this grep: grep '\.zip' /usr/portage/*/*/*ebuild \ | grep -v -e http -e ftp -e mirror -e unpack -e SRC_URI -e unzip It produced a reasonable number of results, and I didn't investigate further. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpo1vLZKbpiP.pgp Description: PGP signature
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
If an ebuild lists bzip2 in DEPEND, the package manager has to bring it in.
The proposed method would only add automatically determined dependencies, not
remove what you listed in DEPEND.
A hypothetical problem is; If a package source file has a bz extension but does
not need bzip2 in any way, an extra dependency is in effect. But can this
situation ever happen ? I guess not.
Rémi Cardona demis ki::
Fabian Groffen wrote:
Manual override as in emerge --nodeps or something.
No, manual override as in the ebuild turns off auto-detection and
specifically asks for app-arch/{bzip2,gzip,tar,whatever} using DEPEND
Cheers,
Rémi
--
Gokdeniz Karadag
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: auto-detection of unpack dependencies
Ciaran McCreesh wrote: On Tue, 15 Jul 2008 12:23:08 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Could someone explain why manually doing work is better than automatically detecting the deps? This sounds like an argument against automation, and I'm not following it. Sometimes the magic will be wrong. For example, packages that have a .zip file in SRC_URI but that don't unpack that file (say, if they install it into sharedir as-is instead) don't need a dep upon unzip. Couldn't the ebuild be wrong? For example, if the package manager uses fancy-unzip-replacement to unzip packages, but the ebuild depends on unzip, then wouldn't it fail? It seems like we're trying to have ebuilds DEPEND on something that in reality the package manager is doing. Shouldn't the package manager depend on unzip instead? If circular references are the problem, then wouldn't it be better to find a better way to handle circular references (ie more specific ways of defining dependencies)? The advantage I see with automagic PM dependency calculations is that the PM is the program calling unzip, so the PM ought to be able to figure out whether it needs to call unzip. smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] Re: RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 16:45:38 -0400 Richard Freeman [EMAIL PROTECTED] wrote: Couldn't the ebuild be wrong? For example, if the package manager uses fancy-unzip-replacement to unzip packages, but the ebuild depends on unzip, then wouldn't it fail? It seems like we're trying to have ebuilds DEPEND on something that in reality the package manager is doing. For current EAPIs, we pretty much mandate that 'unzipping .zip files is done using app-arch/unzip'. It's not ideal. For future EAPIs, we can have the package manager define super-magic/thing-i-use-to-unzip. Shouldn't the package manager depend on unzip instead? If circular references are the problem, then wouldn't it be better to find a better way to handle circular references (ie more specific ways of defining dependencies)? Having the package manager depend upon things like 7z for the two packages in the tree that use it isn't sane. One could argue that having package manager support for extracting 7z is also not sane, of course, but that's something we're stuck with in current EAPIs. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 19:12:37 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008 04:14:18 +0200 Marius Mauch [EMAIL PROTECTED] wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' Could do it just as an eclass... inherit work-out-my-unpack-deps-for-me In principle, there's nothing that can't be done on the ebuild side here. Right, just I'd expect the parsing of SRC_URI (with conditionals) to be a bit tricky in bash, not something I'm going to work on. An eclass-based solution would have a few benefits though wrt the metadata cache. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 23:23:26 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
Right, just I'd expect the parsing of SRC_URI (with conditionals) to
be a bit tricky in bash, not something I'm going to work on. An
eclass-based solution would have a few benefits though wrt the
metadata cache.
Well... You don't really have to parse it.
for p in $SRC_URI ; do
if [[ ${p} == ( ]] || [[ ${p} == ) ]] || \
[[ ${p%\?} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} $p
elif [[ ${p%.zip} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/unzip
elif [[ ${p%.bz2} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/bzip2
fi
done
Granted, it'll generate invalid output if SRC_URI is invalid (for
example, if SRC_URI has mismatched parens, the output will too), but I
can't think of any situation where breaking DEPEND if SRC_URI is
already broken is a problem.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: RFC: auto-detection of unpack dependencies
Ciaran McCreesh wrote: For future EAPIs, we can have the package manager define super-magic/thing-i-use-to-unzip. ++ One could argue that having package manager support for extracting 7z is also not sane, of course, but that's something we're stuck with in current EAPIs. Or we could allow users to decide for themselves with IUSE=7z in the package manager ebuild. Granted, it would be a bit of a pain predicting what formats your package manager will need to handle. smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] Re: RFC: auto-detection of unpack dependencies
Ciaran McCreesh wrote: For future EAPIs, we can have the package manager define super-magic/thing-i-use-to-unzip. ++ One could argue that having package manager support for extracting 7z is also not sane, of course, but that's something we're stuck with in current EAPIs. Or we could allow users to decide for themselves with IUSE=7z in the package manager ebuild. Granted, it would be a bit of a pain predicting what formats your package manager will need to handle. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: RFC: auto-detection of unpack dependencies
Patrick Börjesson wrote: On 2008-07-15 21:40, Tiziano Müller uttered these thoughts: Marius Mauch wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' [snip] So, is this something ebuild maintainers would like in general, or does such a feature cause you nightmares? Yes. I think that's something which should be done manually. Indeed, the correct solution would be to state the deps manually in each ebuild that requires the dep. But in this case it would mean adjusting the DEPEND string of pretty much the entire tree. Until such measures are stated required, this would be a good middle ground, no? no. How about just introducing the new deps on their next version or revision bump? (I assume that more than half of the packages would be fixed within the next half year and that's more than fast enough). The same thing would apply to gcc if all real depends were to be required in all ebuilds, but that would pretty much have to be manually stated since the PM wouldn't be able to judge that by automatic measures. This, on the other hand, can (at least partially) be handled automatically for the ebuild-devs on the PM side of things. That's a different thing: A dependency on gcc just ensures that gcc is installed not that it is actually used to build a package. And for such a dependency we'd need new ways to express deps since gcc is only needed when building packages not when it gets installed from a binpkg. But this is not an argument for an automagic dep. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 22:34:33 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 15 Jul 2008 23:23:26 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
Right, just I'd expect the parsing of SRC_URI (with conditionals) to
be a bit tricky in bash, not something I'm going to work on. An
eclass-based solution would have a few benefits though wrt the
metadata cache.
Well... You don't really have to parse it.
for p in $SRC_URI ; do
if [[ ${p} == ( ]] || [[ ${p} == ) ]] || \
[[ ${p%\?} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} $p
elif [[ ${p%.zip} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/unzip
elif [[ ${p%.bz2} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/bzip2
fi
done
Granted, it'll generate invalid output if SRC_URI is invalid (for
example, if SRC_URI has mismatched parens, the output will too), but I
can't think of any situation where breaking DEPEND if SRC_URI is
already broken is a problem.
Interesting idea. Unfortunately our depstring parser doesn't like empty
parentheses (as they are usually problem indicators), so it doesn't
work out.
Marius
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Wed, 16 Jul 2008 00:43:28 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
Interesting idea. Unfortunately our depstring parser doesn't like
empty parentheses (as they are usually problem indicators), so it
doesn't work out.
Bleh. You can hack around that using a second (looping) pass then. I
think this is right, assuming extglob:
for p in $SRC_URI ; do
if [[ ${p} == ( ]] || [[ ${p} == ) ]] || \
[[ ${p%\?} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} $p
elif [[ ${p%.zip} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/unzip
elif [[ ${p%.bz2} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/bzip2
fi
done
while true ; do
UNPACK_DEPENDS= ${UNPACK_DEPENDS}
u=${UNPACK_DEPENDS}
UNPACK_DEPENDS=${UNPACK_DEPENDS//?(+( )+([^ ])\?)+( )(+( ))+( )/ }
[[ $u == ${UNPACK_DEPENDS} ]] break
done
Although... Allowing ( ) makes much more sense...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Re: RFC: auto-detection of unpack dependencies
On 2008-07-15 22:58, Tiziano Müller uttered these thoughts: Patrick Börjesson wrote: On 2008-07-15 21:40, Tiziano Müller uttered these thoughts: The same thing would apply to gcc if all real depends were to be required in all ebuilds, but that would pretty much have to be manually stated since the PM wouldn't be able to judge that by automatic measures. That's a different thing: A dependency on gcc just ensures that gcc is installed not that it is actually used to build a package. Not quite sure what you mean here. I'm just saying that if you want to go the route of stating all deps explicitly, you have to state in the ebuild (DEPENDS) that gcc is needed to build the package, if that's the case. I'm not against this at all (I'm not an ebuild-maintainer), i just gave an example for when there's no sane way for the PM to automatically inject a dependency. And for such a dependency we'd need new ways to express deps since gcc is only needed when building packages not when it gets installed from a binpkg. Portage (or whichever PM you want) uses it's own way of packaging binpkgs, so for it to be able to extract those binpkgs, a RDEPEND on the applications used for that specific task has to be stated in the _PM_ itself. It isn't the ebuild deciding which format it's gonna be packaged down into. I'm far from sure about this, but DEPENDS aren't really taken into consideration when installing from a binpkg, so stating (f.ex) gcc in DEPENDS wouldn't draw it in when you install the package from a binpkg. It is however known to the ebuild-maintainer and/or the PM which format the source is packaged in, so that's a sane thing to put in DEPEND, whether by manual editing of the ebuild/eclass, or by automation in the PM. Patrick B -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpXag0IuOJCu.pgp Description: PGP signature
[gentoo-dev] Re: LDFLAGS=-Wl,--hash-style=gnu
On Tue, 15 Jul 2008 21:39:00 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: On 15-07-2008 15:32:32 -0400, Doug Goldstein wrote: all, I'm at the point that -Wl,-O1 appears to be successful. It's time to toss on -Wl,--hash-style=gnu. The issue is that we need glibc 2.5 or higher and not mips. So one solution is to put the following: default/linux: LDFLAGS=-Wl,-O1,--hash-style=gnu default/linux/mips: LDFLAGS=-Wl,-O1 However, this means we'll have to put a has_version check in profile.bashrc of default/linux, which seems a bit cludgy.. Any suggestions? Comments? Also sys-devel/binutils-2.17. I'm just wondering... unless it has changed since last time I installed Gentoo Linux, but isn't the installation manual on purpose conservative with CFLAGS? make.conf.example also does not much more than -march -O2 -pipe. -O1 to the linker feels conservative to me. Still, do we really need to go any further? Why not make additional pointers to possible values for LDFLAGS like we do for C(XX)FLAGS in the installation manual? +1. The default is already to generate a GNU style hash when available. I really don't know why we need to screw with it further. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: LDFLAGS=-Wl,--hash-style=gnu
Ryan Hill wrote: On Tue, 15 Jul 2008 21:39:00 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: On 15-07-2008 15:32:32 -0400, Doug Goldstein wrote: all, I'm at the point that -Wl,-O1 appears to be successful. It's time to toss on -Wl,--hash-style=gnu. The issue is that we need glibc 2.5 or higher and not mips. So one solution is to put the following: default/linux: LDFLAGS=-Wl,-O1,--hash-style=gnu default/linux/mips: LDFLAGS=-Wl,-O1 However, this means we'll have to put a has_version check in profile.bashrc of default/linux, which seems a bit cludgy.. Any suggestions? Comments? Also sys-devel/binutils-2.17. I'm just wondering... unless it has changed since last time I installed Gentoo Linux, but isn't the installation manual on purpose conservative with CFLAGS? make.conf.example also does not much more than -march -O2 -pipe. -O1 to the linker feels conservative to me. Still, do we really need to go any further? Why not make additional pointers to possible values for LDFLAGS like we do for C(XX)FLAGS in the installation manual? +1. The default is already to generate a GNU style hash when available. I really don't know why we need to screw with it further. It's actually not. In Gentoo we patch this to use 'both' as the default. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: LDFLAGS=-Wl,--hash-style=gnu
On Tue, 15 Jul 2008 22:09:36 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ryan Hill wrote: On Tue, 15 Jul 2008 21:39:00 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: On 15-07-2008 15:32:32 -0400, Doug Goldstein wrote: all, I'm at the point that -Wl,-O1 appears to be successful. It's time to toss on -Wl,--hash-style=gnu. The issue is that we need glibc 2.5 or higher and not mips. So one solution is to put the following: default/linux: LDFLAGS=-Wl,-O1,--hash-style=gnu default/linux/mips: LDFLAGS=-Wl,-O1 However, this means we'll have to put a has_version check in profile.bashrc of default/linux, which seems a bit cludgy.. Any suggestions? Comments? Also sys-devel/binutils-2.17. I'm just wondering... unless it has changed since last time I installed Gentoo Linux, but isn't the installation manual on purpose conservative with CFLAGS? make.conf.example also does not much more than -march -O2 -pipe. -O1 to the linker feels conservative to me. Still, do we really need to go any further? Why not make additional pointers to possible values for LDFLAGS like we do for C(XX)FLAGS in the installation manual? +1. The default is already to generate a GNU style hash when available. I really don't know why we need to screw with it further. It's actually not. In Gentoo we patch this to use 'both' as the default. Yes, which generates a GNU style hash (along with a SysV one). True? If both are available and the linker understands .gnu.hash, it uses it. Unless having both is detrimental due to the added size (i honestly don't know), this seems the best option to me. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] LDFLAGS=-Wl,--hash-style=gnu
Fabian Groffen wrote: I'm just wondering... unless it has changed since last time I installed Gentoo Linux, but isn't the installation manual on purpose conservative with CFLAGS? make.conf.example also does not much more than -march -O2 -pipe. -O1 to the linker feels conservative to me. Still, do we really need to go any further? Why not make additional pointers to possible values for LDFLAGS like we do for C(XX)FLAGS in the installation manual? CFLAGS != LDFLAGS, so the installation handbook has never covered them. And yes, we are conservative in our documentation with regards to optimization, because that's the smart choice. Ya'll may want to take a look at the compilation optimization guide at [1], specifically the FAQ on LDFLAGS. I may need to reword this section a bit given how the stance on LDFLAGS has shifted. [1] http://www.gentoo.org/doc/en/gcc-optimization.xml#doc_chap3_sect4 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: RFC: auto-detection of unpack dependencies
On Tue, Jul 15, 2008 at 1:58 PM, Tiziano Müller [EMAIL PROTECTED] wrote: Patrick Börjesson wrote: On 2008-07-15 21:40, Tiziano Müller uttered these thoughts: Marius Mauch wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' [snip] So, is this something ebuild maintainers would like in general, or does such a feature cause you nightmares? Yes. I think that's something which should be done manually. Indeed, the correct solution would be to state the deps manually in each ebuild that requires the dep. But in this case it would mean adjusting the DEPEND string of pretty much the entire tree. Until such measures are stated required, this would be a good middle ground, no? no. How about just introducing the new deps on their next version or revision bump? (I assume that more than half of the packages would be fixed within the next half year and that's more than fast enough). Why would you do a bunch of manual work when you can script it easily with few false positives? Doubly so when false positives are relatively cheap; adding an extra dep on a package you probably already have installed won't hurt much and those it does hurt can file bugs for the RESTRICT and/or explicitly state the dep. We could alternatively just use this automatic system to automatically modify DEPEND in the majority of ebuilds and work the bugs out that way. I think doing this entirely manually is just a waste of your time though ;) -Alec The same thing would apply to gcc if all real depends were to be required in all ebuilds, but that would pretty much have to be manually stated since the PM wouldn't be able to judge that by automatic measures. This, on the other hand, can (at least partially) be handled automatically for the ebuild-devs on the PM side of things. That's a different thing: A dependency on gcc just ensures that gcc is installed not that it is actually used to build a package. And for such a dependency we'd need new ways to express deps since gcc is only needed when building packages not when it gets installed from a binpkg. But this is not an argument for an automagic dep. -- gentoo-dev@lists.gentoo.org mailing list -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] LDAP use flag / openssh
Hi List, first of, I am no dev, but I was really wondering, why ldap is a default useflag in the 2008.0 desktop profile, maybe someone could enlighten me? I am especially wondering, why would the average desktop user want LDAP but not samba, for CIFS etc. ? I guess, the ways, of the devs are somewhat mysterious, so, okay, let's stick stick with the LDAP useflag, no biggy. What I particularly wonder about: LDAP is a default use flag (in desktop). Now, openssh got an LDAP useflag, but for ages all ebuilds drop out, saying one should mask 'em, since ldap doesn't work with the particular version. What I really don't understand: If the feature is broken (which I don't know, but assume due to the ebuild message), why is it, that the flag did not get removed? Is it typical policy to keep useflags for broken features? Please don't get me wrong, all I am looking for is some enlightenment in this case ... With best Regards -Sven P.S.: If I am just stupid or ignorant and missed out on something, please tell me so. -- gentoo-dev@lists.gentoo.org mailing list
