Re: [gentoo-dev] Reminder on dependencies.
On Thursday 27 October 2005 02:15, Luca Barbato wrote: > Paul de Vrieze wrote: > > I agree here. If you don't want packages to be pulled in because of > > header files, you need support for that (perhaps in the form of > > subpackages, or a useflag). But IF the header files of a package are > > installed one should be able to assume that they keep on working. > > Even after buildtime-only dependencies have been removed. > > I agree too > > > In the case of embedded it is clear that what in binary distributions > > is part of the development package (.la files, static libraries, > > header files) is not desired at all. To break dependencies to only > > strip away some of the headers seems to me a half solution that > > breaks a lot and doesn't solve the problem either. > > > > Paul > > Btw embedded has already different way to archive the same result (ok, > removing headers and static libs after isn't really the cleanest > solution but works fine) The hardest part is probably to build all these packages as the finals shouldn't have headers while the intermediates (used to build other finals against) should. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpmvhJTI56nX.pgp Description: PGP signature
Re: [gentoo-dev] Reminder on dependencies.
On Thu, 2005-27-10 at 09:36 +0200, Paul de Vrieze wrote: > On Thursday 27 October 2005 02:15, Luca Barbato wrote: > > Paul de Vrieze wrote: > > > In the case of embedded it is clear that what in binary distributions > > > is part of the development package (.la files, static libraries, > > > header files) is not desired at all. To break dependencies to only > > > strip away some of the headers seems to me a half solution that > > > breaks a lot and doesn't solve the problem either. > > > > Btw embedded has already different way to archive the same result (ok, > > removing headers and static libs after isn't really the cleanest > > solution but works fine) > > The hardest part is probably to build all these packages as the finals > shouldn't have headers while the intermediates (used to build other > finals against) should. Again, why not leave everything in the packages and use INSTALL_MASK on embedded systems ? -- Olivier Crête [EMAIL PROTECTED] x86 Security Liaison signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Reminder on dependencies.
On Thu, 2005-10-27 at 09:40 -0400, Olivier Crête wrote: > On Thu, 2005-27-10 at 09:36 +0200, Paul de Vrieze wrote: > > On Thursday 27 October 2005 02:15, Luca Barbato wrote: > > > Paul de Vrieze wrote: > > > > In the case of embedded it is clear that what in binary distributions > > > > is part of the development package (.la files, static libraries, > > > > header files) is not desired at all. To break dependencies to only > > > > strip away some of the headers seems to me a half solution that > > > > breaks a lot and doesn't solve the problem either. > > > > > > Btw embedded has already different way to archive the same result (ok, > > > removing headers and static libs after isn't really the cleanest > > > solution but works fine) > > > > The hardest part is probably to build all these packages as the finals > > shouldn't have headers while the intermediates (used to build other > > finals against) should. > > Again, why not leave everything in the packages and use INSTALL_MASK on > embedded systems ? This thread can end. ciaranm provided an example yesterday and his case is pretty much for c++ templates and the cases I'm making are for things like (example thats no longer valid) wireless-tools pulling in linux headers and or source into a $ROOT via $RDEPEND due some eclass. INSTALL_MASK was created for embedded systems by iggy to partially deal with this sorta problem. It helps but it's not the end all solution. -- Ned Ludd <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-core] Re: [gentoo-dev] Possible virtual/alsa change
On Mon, 2005-10-24 at 15:41 -0400, Stephen P. Becker wrote: > Currently, we have two machines with alsa drivers (only one of which > *really* works, but that is beside the point), and the working driver is > applied to our mips-sources-2.6.* ebuilds along with the patchset for > octane. However, this information is pretty irrelevent from my point of > view. The real problems are that A) alsa-driver doesn't contain any > mips drivers, B) 2.4 kernel sources do not contain the alsa drivers > while 2.6 do, and C) that mips-sources included both 2.4 and 2.6. > Therefore, we really do not have anything generic that can be changed to > the default virtual for us without being broken (until such time as we > can finally get rid of 2.4). I don't have a solution at this point in > time either...I'm just saying how things are. I dont see this as a real reason to not change the default personally. mips-sources exists in the tree for a reason, and are being actively maintained. by setting the default virtual for alsa-sound to gentoo-sources surely wont effect you anyways, considering alsa-drivers doesn't work, gentoo-sources likely dont work, and mips-sources provide virtual/alsa? If at some point alsa-drivers decides to work, then can you not just redefine the virtual in the mips profile? Anyways, I see no real point here to prevent the move, however I found it educational re: alsa-driver :) -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-core] Re: [gentoo-dev] Possible virtual/alsa change
dont see this as a real reason to not change the default personally. mips-sources exists in the tree for a reason, and are being actively maintained. by setting the default virtual for alsa-sound to gentoo-sources surely wont effect you anyways, considering alsa-drivers doesn't work, gentoo-sources likely dont work, and mips-sources provide virtual/alsa? The problem is that *all* mips-sources ebuilds do not provide alsa. Only the mips-sources-2.6.* versions do this, and then only if USE="ip30" (Octane users). If at some point alsa-drivers decides to work, then can you not just redefine the virtual in the mips profile? Sure, it would be no problem in that case. Anyways, I see no real point here to prevent the move, however I found it educational re: alsa-driver :) I'm just worried about folks running 2.4 systems (only Indys at this point) with mips-sources "providing" alsa, but not really. This could get even more tricky because I happen to know somebody is working on an alsa driver for Indy, and it will be for 2.6 only. We're trying really hard to get everything to where we can just get rid of 2.4, but until that time, setting the virtual to mips-sources is technically broken. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-core] Re: [gentoo-dev] Possible virtual/alsa change
On Thu, 2005-10-27 at 14:28 -0400, Stephen P. Becker wrote: > The problem is that *all* mips-sources ebuilds do not provide alsa. > Only the mips-sources-2.6.* versions do this, and then only if > USE="ip30" (Octane users). This makes sense, although not the USE flag. > I'm just worried about folks running 2.4 systems (only Indys at this > point) with mips-sources "providing" alsa, but not really. This could > get even more tricky because I happen to know somebody is working on an > alsa driver for Indy, and it will be for 2.6 only. We're trying really > hard to get everything to where we can just get rid of 2.4, but until > that time, setting the virtual to mips-sources is technically broken. Of course, 2.4 kernels are technically broken because they dont support alsa, and this is fixed in other profiles with the inclusion of a 2.4 (or 2.6) sub profile. However.. if nothing actually works with alsa, then I dont see the problem in that case of making the profile default mips-sources. if it happens to install 2.4 sources, then so be it. it might be a technically incorrect provide.. but nothing else can fill it any better. At least at this moment in time. If it were me, thats what I would do. But of course, this change doesn't really make any difference to mips one way or the other. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 -- gentoo-dev@gentoo.org mailing list
