[gentoo-dev] gtk1 vs. gtk2
Hi folks, I've seen an ugly problem w/ gtk1 + gtk2. These two different packages are treated as one. Obviously very bad behaviour. http://bugs.gentoo.org/show_bug.cgi?id=143063 IMHO this is a major problem, and we should fix it soon. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
On Mon, 7 Aug 2006 09:43:00 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: | I've seen an ugly problem w/ gtk1 + gtk2. These two different | packages are treated as one. Obviously very bad behaviour. Uh, they're in different slots, so no, they're not treated as one. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Setting USE_EXPAND defaults in profiles (in some cases)
Zac Medico wrote: Donnie Berkholz wrote: agaffney suggested this in the first place, and every time I think about it, it seems like a better idea. If we set VIDEO_CARDS and INPUT_DEVICES in the arch profiles, we get the arch-specific defaults we need without the really hugely ugly indecipherable mess in the ebuilds that nobody can understand besides Josh_B and me. The very strange corner case this doesn't work with is if people manually set VIDEO_CARDS=, then they will no longer get the behavior of pulling in everything. But the default case will still work great. As of portage-2.1.1_pre4-r4, VIDEO_CARDS= should now continue to work like before no matter how you've enabled the flags in the profile. As part of the fix for bug 142125, portage automatically regenerates all of the USE_EXPAND variables to be consistent with the corresponding USE flags. Zac Well, please don't change the behaviour in every other release, it's very confusing and people file bugs about it. And -r4 behaviour is incorrect, as it ignores defaults in profiles when you set anything in make.conf. -r3 got it correctly so that foo in profiles could be overriden with -foo in make.conf, this doesn't work any more in -r4. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Setting USE_EXPAND defaults in profiles (in some cases)
On Mon, Aug 07, 2006 at 10:01:12AM +0200, Jakub Moc wrote: Zac Medico wrote: Donnie Berkholz wrote: agaffney suggested this in the first place, and every time I think about it, it seems like a better idea. If we set VIDEO_CARDS and INPUT_DEVICES in the arch profiles, we get the arch-specific defaults we need without the really hugely ugly indecipherable mess in the ebuilds that nobody can understand besides Josh_B and me. The very strange corner case this doesn't work with is if people manually set VIDEO_CARDS=, then they will no longer get the behavior of pulling in everything. But the default case will still work great. As of portage-2.1.1_pre4-r4, VIDEO_CARDS= should now continue to work like before no matter how you've enabled the flags in the profile. As part of the fix for bug 142125, portage automatically regenerates all of the USE_EXPAND variables to be consistent with the corresponding USE flags. Zac Well, please don't change the behaviour in every other release, it's very confusing and people file bugs about it. And -r4 behaviour is incorrect, as it ignores defaults in profiles when you set anything in make.conf. -r3 got it correctly so that foo in profiles could be overriden with -foo in make.conf, this doesn't work any more in -r4. That was a bug, not a feature. Older portage versions behave as -r4 does, and -r3's behaviour forces users to set invalid values in certain cases. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Developer Upgrade! Steve Dibbs
On 2006.08.07 00:20, Christel Dahlskjaer wrote: Hi all, It is with geat pleasure that I can knight Steve (aka beandog) a 'real dev'. Under Mike (KingTacos) hawkeyed glance I have recruited my first recruitee (hmm, it's not really called recruitee is it?) and am embarking upon a joyful^Wstressful time as a recruiter.. [snip] Christelxx -- $a=gentoo.org; Christel Dahlskjaer | [EMAIL PROTECTED] | www.$a Gentoo Developeress - User Relations, Developer Relations, Gentoo/MIPS, Gentoo/Alpha, PR, Events, Release Engineering -- gentoo-dev@gentoo.org mailing list Congratulations ... to you both. Regards, Roy Bamford -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
You've already been told it's a non-issue, but here's why: http://devmanual.gentoo.org/general-concepts/slotting/index.html -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
* Simon Stelling [EMAIL PROTECTED] schrieb: You've already been told it's a non-issue, but here's why: http://devmanual.gentoo.org/general-concepts/slotting/index.html Oh hell, this can't be serious ! It mixes up diffent things to one and just introduces new problems instead of solving anything. I could live with that, if it's for supporting different ABIs, but it obviously isn't. gtk1 and gtk2 are completely different packages, they're not compatible. So why should they be one package ? Just because they share some ideas and the name ?! For example, there are lots of packages requiring gtk1, other gtk2. As long as dependencies don't cope the slot cleanly, slotting is utterly useless. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] PDA herd call for assistance
* Chris White [EMAIL PROTECTED] schrieb: Hi, That said I'm looking around for people that can help with confirmations/patches/etc. for app-pda packages. I'm going to take a deeper look at the synce stuff in a few days, so I'll probably have to fix a lot of things there anyways. You may add me to your maillist(s) and CC me to bugs at will. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: It mixes up diffent things to one and just introduces new problems instead of solving anything. I could live with that, if it's for supporting different ABIs, but it obviously isn't. No? gtk1 and gtk2 are completely different packages, they're not compatible. So why should they be one package ? Just because they share some ideas and the name ?! Because gtk-2.xx is originated from gtk+-1.2.xx and you still have a common set of widget API ? For example, there are lots of packages requiring gtk1, other gtk2. As long as dependencies don't cope the slot cleanly, slotting is utterly useless. gtk-1 is deprecated, it will disappear sooner or later. -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: Oh hell, this can't be serious ! It is. It mixes up diffent things to one and just introduces new problems instead of solving anything. I could live with that, if it's for supporting different ABIs, but it obviously isn't. What sort of problems? An example backing up your claims would be very nice. gtk1 and gtk2 are completely different packages, they're not compatible. So why should they be one package ? Just because they share some ideas and the name ?! Yes. Why not, after all? For example, there are lots of packages requiring gtk1, other gtk2. As long as dependencies don't cope the slot cleanly, slotting is utterly useless. =x11-libs/gtk+-1.2* x11-libs/gtk+-2 do a decent job. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Masking practics
big_snip / My problem still seems unsolved (or did I miss something) ? Lets say, if I've, installed foo-1.1, and it gets masked due some bug(s), but 1.0 isn't, I want to get informed with an big fat warning, *before* anything actually done, ie. [...] # WARNING: installed package foo-1.1 has been masked and would # be downgraded: # masking comment ... [...] An fully-automatic downgrade should *never* downgrade anything. This is too dangerous, because essential features can get lost. Again, my bugzilla example: assuming 2.22 will be unmasked some day and I installed it w/ postgres support. Now there are some bugs found, but not fixed fast enough, so it gets masked. I run an update w/o knowing that it downgrades, and my whole bugzilla hosting is suddenly broken. Do you consider this as stability, seriously ?! cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] PDA herd call for assistance
Enrico Weigelt wrote: I'm going to take a deeper look at the synce stuff in a few days, so I'll probably have to fix a lot of things there anyways. You may add me to your maillist(s) and CC me to bugs at will. http://bugs.gentoo.org/userprefs.cgi?tab=email has a 'Users to watch:' input field. Just add the PDA herd's email address there and you will receive all their bug mails, which has the advantage of not causing a lot of bugzi spam. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Masking practics
On Mon, 2006-08-07 at 15:01 +0200, Enrico Weigelt wrote: Lets say, if I've, installed foo-1.1, and it gets masked due some bug(s), but 1.0 isn't, I want to get informed with an big fat warning, *before* anything actually done, ie. [...] # WARNING: installed package foo-1.1 has been masked and would # be downgraded: # masking comment ... [...] An fully-automatic downgrade should *never* downgrade anything. This is too dangerous, because essential features can get lost. Again, my bugzilla example: assuming 2.22 will be unmasked some day and I installed it w/ postgres support. Now there are some bugs found, but not fixed fast enough, so it gets masked. I run an update w/o knowing that it downgrades, and my whole bugzilla hosting is suddenly broken. That would not happen. bugzilla is a webapp and as such is fully SLOTted. Upgrades (and downgrades) are manual. Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Masking practics
Enrico Weigelt wrote: big_snip / My problem still seems unsolved (or did I miss something) ? Lets say, if I've, installed foo-1.1, and it gets masked due some bug(s), but 1.0 isn't, I want to get informed with an big fat warning, *before* anything actually done, ie. [...] # WARNING: installed package foo-1.1 has been masked and would # be downgraded: # masking comment ... [...] An fully-automatic downgrade should *never* downgrade anything. This is too dangerous, because essential features can get lost. Again, my bugzilla example: assuming 2.22 will be unmasked some day and I installed it w/ postgres support. Now there are some bugs found, but not fixed fast enough, so it gets masked. I run an update w/o knowing that it downgrades, and my whole bugzilla hosting is suddenly broken. Do you consider this as stability, seriously ?! If your bugzilla hosting breaks with lower versions, then the ebuild contains a RDEPEND=postgres? ( =dev-db/postgresql-2.22 ). Now if =postgresql-2.22 gets masked, portage will bail out with an error because it can't find a valid dependency tree. This will cause the comment above the masking line in p.mask to be shown. You can then decide whether the breakage affects you or not and depending on that unmask it locally or remove your bugzilla installation. If there is a bugzilla-ebuild which works with postgresql-2.22, it will be downgraded too, leaving you with a working bugzilla. I can't quite see the massive problem. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
* Noack, Sebastian [EMAIL PROTECTED] schrieb: snip Hey, come on. We're not Debian! Unnecessary and senseless splitting of packages is against the philosophy of Gentoo. I don't think we are not xyz is a good argumentation in technical discussions. At this point, Debian is actually doing good work. The bad thing is that those things don't get neither into the upstrem nor other distros. That's exactly what my OSS-QM project is for. snip (kde || qt4 || qt3 || qt || gtk) (arts || alsa) (asf win32codecs) IMHO unnecessary complexity which introduces more point of failure and confusion. At the first sight this approach seems to add complexity, but actual it would remove a lot of complexity on Gentoo systems. For example on my own system here I have approx. 40 lines in my /etc/portage/package.use which could be reduced to less than 10 lines by using such a syntax like above in the /etc/make.conf for global useflag configuration. You shouldn't mix up quantity with complexity. If you make handling of badly designed code easier, you take presure from the actual developers. snip With you suggestion, the package maintainers have to take care of Grandma's special conditions. This shouldn't be their job. Granma's Box cries for an special Grandma-Distro, Grandma-Gentoo ! This should be maintained by an separate team, which is specialized on the needs of those users. In the described scenario, it wasn't mentioned that she has a grandchild, so where do you know from that she is a grandma? ;) So no special Grandma-support is needed at all. snip Doesn't matter, btw it was in any case just an example where such a syntax would be useful. Another szenario would be a server with several database-based apps on it, where an expression like (postgres || mysql) might be useful. Aehm, you hopefully know that they don't have very much in common. Please give me an example, where this would be should be useful. RDBMS'es aren't actually things we you could say choose what you like, doesn't matter which one. Yeah, would be nice if it was so, but that's just a nice dream. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Beta versions should be slotable
Hi folks, I like to try bleeding edge beta versions. But I hate that if I will install for example the new firefox 2 beta via portage, it will unmerge the current stable version. I would prefer to have a stable version for daily work and the beta version for testing purposes at the same time on my system. Therefore I would propose to introduce a policy, which forces each ebuild with the suffix _alpha, _beta or _pre have to be slotable. Best Regards Sebastian Noack -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Monday 07 August 2006 15:16, Enrico Weigelt wrote: * Luca Barbato [EMAIL PROTECTED] schrieb: snip For example: mplayer It has it's gui-less player and an gtk-based frontend in one package. We should split this into two packages: mplayer and gmplayer. The chances to get this done in the upstream *before* some major distro like gentoo does the split by its own are quite low. We do not split packages for frivolous reasons. Well, I don't consider reducing complexity frivolous ;-o Which reduction for which complexity? Do you want to bring everyone's systems to a grinding halt, just because you can't understand the complexity of useflags. Useflags are one of the distinguishing features of gentoo. Now you opt to do away with them. I do not see the reason. It is also against the gentoo philosophy of offering software the way upstream provides it. snip Some people @mplayerhq are quite aeh, unfortunate, about changes in the build procedure. Maybe you like to have a look at the discussion about my patches introducing pkg-config utilization. pkg-config is a broken concept. Libraries themselves should state dependency information. Pkg-config is a solution that introduces at least as many problems as it solves. Only libtool (esp. old versions) is worse in it's incomplete use of the linker and the way it encourages broken library linking. That's the right ways. And so gmplayer stuff should be dropped completely. If you like, I'll sit down and fix the ebuilds. First fix your attitude problem, then come with good suggestions stated in a more friendly way. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3sJxZmsRPa.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for advanced useflag-syntax
* Brian Harring [EMAIL PROTECTED] schrieb: snip Additionally... once you start down that path, the changes to pkgs become less then minor. Some are simple, some ain't. If it's required to get them clean, then it shall be done. (I'm actually doing thins @ oss-qm) snip Personally, I hate that approach- ignoring any political/warring idiocy, my main issue with debian is the choice to split upstream packages into multiple sub packages. Makes things a pain in the ass to what you want/need and makes for fun lock-step dependencies between the subpackages. That's just because Debian has to do the upstream's work. The only charge I can make them here, is that they're working too silent instead of making heavy noise in the upstream so that they actually learn what they're doing wrong. It's like washing a child day by day and never showing him why it's wise to wash yourself and how to do it. Let's take a better example: nmap This package actually contains two completely different things: the portscanner tool and some gtk-based frontend. In fact the gtk useflag switches the second package. They're in fact two different applications (just one shipped as an subdir of another) and so should have two ebuilds. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Masking practics
Enrico Weigelt wrote: big_snip / My problem still seems unsolved (or did I miss something) ? Lets say, if I've, installed foo-1.1, and it gets masked due some bug(s), but 1.0 isn't, I want to get informed with an big fat warning, *before* anything actually done, ie. [...] # WARNING: installed package foo-1.1 has been masked and would # be downgraded: # masking comment ... [...] An fully-automatic downgrade should *never* downgrade anything. This is too dangerous, because essential features can get lost. Again, my bugzilla example: assuming 2.22 will be unmasked some day and I installed it w/ postgres support. Now there are some bugs found, but not fixed fast enough, so it gets masked. I run an update w/o knowing that it downgrades, and my whole bugzilla hosting is suddenly broken. Do you consider this as stability, seriously ?! I would call you a horrible administrator since this: I run an update w/o knowing that it downgrades should NEVER happen. emerge -pv foo [ebuild UD] cat/foo-currentversion [downgraded-version] stuff -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Beta versions should be slotable
On Mon, 7 Aug 2006 15:29:53 +0200 Noack, Sebastian [EMAIL PROTECTED] wrote: | I like to try bleeding edge beta versions. But I hate that if I will | install for example the new firefox 2 beta via portage, it will | unmerge the current stable version. I would prefer to have a stable | version for daily work and the beta version for testing purposes at | the same time on my system. Therefore I would propose to introduce a | policy, which forces each ebuild with the suffix _alpha, _beta or | _pre have to be slotable. Too inflexible. Not all upstreams use sane versioning schemes. Now, if we had slot deps, encouraging wider use of slots along with trivial little eselect modules to handle the symlinks might be a good idea, but requiring it is silly. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
That's just because Debian has to do the upstream's work. So if you are so in love with how Debian does everything, why don't you just use Debian instead of Gentoo and stop wasting our time with your silly rants on how we should do everything just like them. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
* Paul de Vrieze [EMAIL PROTECTED] schrieb: snip Well, I don't consider reducing complexity frivolous ;-o Which reduction for which complexity? Do you want to bring everyone's systems to a grinding halt, just because you can't understand the complexity of useflags. I just want to keep things simple. We're talking about introducing new (additional) logic. This has to be maintained. And it doesn't actually *solve* the problem which is this discussion was started. Rember: we started with the thesis, grandma wants graphical frontends whereever possible. This is in fact not an technical issue, instead a matter of personal taste, or lets say, an individual system configuration. Grandma wants to click, okay, so she should use graphical applications. She's not interested what sits behind, she just wants to have a buch of applications. And she also doesn't wann have anything to do with emerge and useflags. She just wants to have a choice between a bunch of end-user applications. That's the job of an Grandma-(sub-)distro. Okay, let's say we want to intruduce an meta-useflag for GUI (although having additional GUIs in the same package as the backend isn't what I consider clean design). If there's just *one* than it's easy - just an alias. But what's if we have more ? Who makes the decision, which one to take ? Based on what rules ? Useflags are one of the distinguishing features of gentoo. Yes. For optional features. Additional programs aren't features of some other program, but additional programs. snip It is also against the gentoo philosophy of offering software the way upstream provides it. Ah, and this philosophy is more important than quality and maintainability ? snip Some people @mplayerhq are quite aeh, unfortunate, about changes in the build procedure. Maybe you like to have a look at the discussion about my patches introducing pkg-config utilization. pkg-config is a broken concept. Ah ? I consider it *very* clean. What could be easier than have an consistent database which *knows* what's installed on the system instead of having to run lots of esoteric tests which shall *guess* it somehow ?! If necessary, this database query can be intercepted easily. With the esoteric testing its very complicated or at least work intensive. BTW: have to ever tried to crosscmompile a whole system in a clean sysroot'ed environment ? snip Libraries themselves should state dependency information. Hah, but only *should*, not actually *do*. Okay, ELF so's can contain such information, but that's only a little part of an library. There's much, much more. Well, how would you get certain search pathes (-I, -L, ...) additional includes, dependency info for evrything but elf-so, ie .a ? Pkg-config is a solution that introduces at least as many problems as it solves. Example ? snip Only libtool (esp. old versions) is worse in it's incomplete use of the linker and the way it encourages broken library linking. Libtool is isn't just broken, it's totally misconception. But that's another story and has *nothing* to do with pkg-config. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Beta versions should be slotable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noack, Sebastian wrote: Hi folks, I like to try bleeding edge beta versions. But I hate that if I will install for example the new firefox 2 beta via portage, it will unmerge the current stable version. I would prefer to have a stable version for daily work and the beta version for testing purposes at the same time on my system. Therefore I would propose to introduce a policy, which forces each ebuild with the suffix _alpha, _beta or _pre have to be slotable. Best Regards Sebastian Noack Not feasable. You have 2 possible ways of doing it though. one is to use a chroot to test these things, and the other is to take a quickpkg of the stable version and emerge -k when you're done testing the bleeding edge stuff. - -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRNdOzoBrouQZ9K4FAQLT+gP/Utlchg/9AG0UK1bGt9YLeDJex9p533Sp emsRmBUDTr+r/iRLpIEoZDcfF/+kPAqQU/tFccaK/6aZdrayfi/DbOIn2wQ+/aAW d82QND8c4wM5lQ8+oxkWU5oxJksIKpwLXh/R7qqSS2LUKXYYiBXEWR+kbdBNDnwS l/5aNmApdCc= =nP1h -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Beta versions should be slotable
On Mon, 2006-08-07 at 09:31 -0500, Mike Doty wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noack, Sebastian wrote: Hi folks, I like to try bleeding edge beta versions. But I hate that if I will install for example the new firefox 2 beta via portage, it will unmerge the current stable version. I would prefer to have a stable version for daily work and the beta version for testing purposes at the same time on my system. Therefore I would propose to introduce a policy, which forces each ebuild with the suffix _alpha, _beta or _pre have to be slotable. Not feasable. You have 2 possible ways of doing it though. one is to use a chroot to test these things, and the other is to take a quickpkg of the stable version and emerge -k when you're done testing the bleeding edge stuff. Is it possible to get Portage (or ebuild) to build a package for installation into /opt? If not, how much work would that be? What would be great would be to have emerge --optinstall package, that installs the package into /opt/$PV and doesn't create a vdb entry... feasible? Ed -- gentoo-dev@gentoo.org mailing list
AW: [gentoo-dev] Beta versions should be slotable
I like to try bleeding edge beta versions. But I hate that if I will install for example the new firefox 2 beta via portage, it will unmerge the current stable version. I would prefer to have a stable version for daily work and the beta version for testing purposes at the same time on my system. Therefore I would propose to introduce a policy, which forces each ebuild with the suffix _alpha, _beta or _pre have to be slotable. Best Regards Sebastian Noack Not feasable. You have 2 possible ways of doing it though. one is to use a chroot to test these things, and the other is to take a quickpkg of the stable version and emerge -k when you're done testing the bleeding edge stuff. The first possibility is crap, because of I would need another entire Gentoo system on my machine which I can chroot into and did you ever tried to get X run out of a chroot environment? Well, it is possible but it needs a lot of work to have a complete redundant functional chroot test environment on your system. Than I would rather prefer to compile the corresponding package by my self and pass --prefix=/usr/bleeding_edge/ to the configure script. And the second possibility you mentioned is also an ugly solution, because of I would have to rollback the stable version by quickpkg every time after testing the beta and vice versa. Regards Sebastian Noack -- gentoo-dev@gentoo.org mailing list
AW: [gentoo-dev] Beta versions should be slotable
Hi folks, I like to try bleeding edge beta versions. But I hate that if I will install for example the new firefox 2 beta via portage, it will unmerge the current stable version. I would prefer to have a stable version for daily work and the beta version for testing purposes at the same time on my system. Therefore I would propose to introduce a policy, which forces each ebuild with the suffix _alpha, _beta or _pre have to be slotable. Not feasable. You have 2 possible ways of doing it though. one is to use a chroot to test these things, and the other is to take a quickpkg of the stable version and emerge -k when you're done testing the bleeding edge stuff. Is it possible to get Portage (or ebuild) to build a package for installation into /opt? If not, how much work would that be? What would be great would be to have emerge --optinstall package, that installs the package into /opt/$PV and doesn't create a vdb entry... feasible? That sounds good. I already thought about making overlays which installs the files into /opt or a new subdir of /usr (for Example /usr/bleeding_edge or so) for all the beta stuff I want to test. But a simple emerge option or a config file like /etc/portage/package.opt would be great. Regards Sebastian Noack -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Beta versions should be slotable
Edward Catmur wrote: Is it possible to get Portage (or ebuild) to build a package for installation into /opt? If not, how much work would that be? What would be great would be to have emerge --optinstall package, that installs the package into /opt/$PV and doesn't create a vdb entry... feasible? Possible, sure: emerge -B package mkdir /opt/package tar -C /opt/package -xjf /usr/portage/packages/All/package-ver.tar.bz2 Smart, not really. Using portage to install packages that are outside of portage's control is kinda silly. If you want to do that, build it by hand or use a pre-compiled package such as a RPM or DEB from the author's site. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
Enrico Weigelt wrote: * Paul de Vrieze [EMAIL PROTECTED] schrieb: snip Well, I don't consider reducing complexity frivolous ;-o Which reduction for which complexity? Do you want to bring everyone's systems to a grinding halt, just because you can't understand the complexity of useflags. I just want to keep things simple. We're talking about introducing new (additional) logic. This has to be maintained. And it doesn't actually *solve* the problem which is this discussion was started. Rember: we started with the thesis, grandma wants graphical frontends whereever possible. This is in fact not an technical issue, instead a matter of personal taste, or lets say, an individual system configuration. Grandma wants to click, okay, so she should use graphical applications. She's not interested what sits behind, she just wants to have a buch of applications. And she also doesn't wann have anything to do with emerge and useflags. She just wants to have a choice between a bunch of end-user applications. That's the job of an Grandma-(sub-)distro. Bad example, as Gentoo generally requires knowledge of the system and the command line interface; unless you think grandma can update her toolchain properly with no issues. I don't think anyone at this point would hand Gentoo to grandma; and I don't think anyone has that goal. Mostly we just want an easy to maintain system. See that word, maintain; generally means the maintainer knows what they are doing. Okay, let's say we want to intruduce an meta-useflag for GUI (although having additional GUIs in the same package as the backend isn't what I consider clean design). If there's just *one* than it's easy - just an alias. But what's if we have more ? Who makes the decision, which one to take ? Based on what rules ? The packages maintainer for Gentoo typically makes the choice on how something is deployed in Gentoo. Useflags are one of the distinguishing features of gentoo. Yes. For optional features. Additional programs aren't features of some other program, but additional programs. I would gather for many packages that a gui is a optional feature. Also this is not a hard and fast rule (and was never meant to be). snip It is also against the gentoo philosophy of offering software the way upstream provides it. Ah, and this philosophy is more important than quality and maintainability ? This *philosophy* is a core value of gentoo. That would be like saying we should build binary packages for everything because it's easier to maintain and gives us a higher quality distribution. Pardon my french, but fuck that. -- gentoo-dev@gentoo.org mailing list
AW: [gentoo-dev] Proposal for advanced useflag-syntax
Well, I don't consider reducing complexity frivolous ;-o Which reduction for which complexity? Do you want to bring everyone's systems to a grinding halt, just because you can't understand the complexity of useflags. I just want to keep things simple. We're talking about introducing new (additional) logic. Is a need to have dozens of lines in your /etc/portage/package.use a simple approach? Maybe it is, if for you, simplicity means only less number of lines of code in the core of the application. But wasn't you the one who told me that quantity isn't the same like complexity? Well you could say that only source code and scripts contain logic and therefore numbers of lines in the config files doesn't means complexity, but what do I do by the config files of portage actually? I use them for example to instruct portage to enable useflag A but not for ebuild and useflag B but just for ebuild b. Do you claim that this is no logic? Rember: we started with the thesis, grandma wants graphical frontends whereever possible. This is in fact not an technical issue, instead a matter of personal taste, or lets say, an individual system configuration. Grandma wants to click, okay, so she should use graphical applications. She's not interested what sits behind, she just wants to have a buch of applications. And she also doesn't wann have anything to do with emerge and useflags. She just wants to have a choice between a bunch of end-user applications. That's the job of an Grandma-(sub-)distro. That was never the point where we started. That was just the point, you used to confuse this discussion. The grandma scenario should just be a funny example for a requirement of such a advanced portage syntax I could really need on my own systems and I'm not female, but male and not 80 but 18 years old. ;) I know that my proposed syntax isn't a perfect solution. But I think the current state of portage isn't a perfect solution, too. And I hoped when I started this thread, that we will find together a good solution. Best Regards Sebastian Noack -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Mon, 7 Aug 2006 15:26:44 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: The bad thing is that those things don't get neither into the upstrem nor other distros. ^--- This should be a warning flag ---^ If other distros aren't doing it and upstream isn't doing it, then it may no be that great of an idea. -Thomas pgpLQVi8H7Dgw.pgp Description: PGP signature
Re: AW: [gentoo-dev] Proposal for advanced useflag-syntax
Noack, Sebastian wrote: Is a need to have dozens of lines in your /etc/portage/package.use a simple approach? Maybe it is, if for you, simplicity means only less number of lines of code in the core of the application. But wasn't you the one who told me that quantity isn't the same like complexity? Well you could say that only source code and scripts contain logic and therefore numbers of lines in the config files doesn't means complexity, but what do I do by the config files of portage actually? I use them for example to instruct portage to enable useflag A but not for ebuild and useflag B but just for ebuild b. Do you claim that this is no logic? I claim that is simple and you should wait at least 24 h before posting on -dev. That was never the point where we started. That was just the point, you used to confuse this discussion. The grandma scenario should just be a funny example for a requirement of such a advanced portage syntax I could really need on my own systems and I'm not female, but male and not 80 but 18 years old. ;) Poor you. I know that my proposed syntax isn't a perfect solution. But I think the current state of portage isn't a perfect solution, too. And I hoped when I started this thread, that we will find together a good solution. You can just write something like flagedit for your extreme uses. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] SearchSecurity.com: Linux patch problems: Your distro may vary
Hi, I just stumbled over an article from SearchSecurity.com which was linked to in a heise newsticker posting that tries to analyze how fast distributions react to security vulnerabilities: http://tinyurl.com/lplfb Quick chart: Rank DistroPoints/100 - -- 1. Ubuntu76 2. Fedora Core 70 3. Red Hat Enterprise Linux 63 4. Debian GNU/Linux 61 5. Mandriva Linux54 6. Gentoo Linux 39 7. Trustix Secure Linux 32 8. SUSE Linux Enterprise 32 9. Slackware Linux 30 Rank 6 out of 10 is not a great result -- at least we beat SUSE ;) Any comments or thoughts about this? Can we become better? Are we maybe better than the author pretends? Does the security team currently face serious problems that need to be solved, be it inside or outside the security team? I am just curious and would be glad to get some feedback :) -- Regards, Wolfram Schlich [EMAIL PROTECTED] Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SearchSecurity.com: Linux patch problems: Your distro may vary
Wolfram Schlich wrote: Any comments or thoughts about this? Read the comments here: http://lwn.net/Articles/193107/ In the future, please don't double-post to subscriber-only lists, very few people can reply to both. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] SearchSecurity.com: Linux patch problems: Your distro may vary
Wolfram Schlich wrote: Any comments or thoughts about this? Does the security team currently face serious problems that need to be solved, be it inside or outside the security team? As far as I know large chunks of time get lost when waiting for maintainers and arch teams to do their work. I don't see how the security team could do much about this; except maybe giving them a yearly budget to travel around the world and slap people who seem to ignore security bugs. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Beta versions should be slotable
On Mon, 2006-08-07 at 09:52 -0500, Andrew Gaffney wrote: Edward Catmur wrote: Is it possible to get Portage (or ebuild) to build a package for installation into /opt? If not, how much work would that be? What would be great would be to have emerge --optinstall package, that installs the package into /opt/$PV and doesn't create a vdb entry... feasible? Possible, sure: emerge -B package mkdir /opt/package tar -C /opt/package -xjf /usr/portage/packages/All/package-ver.tar.bz2 Yeah, but the internals'd be screwy; hardcoded paths would point to the /-based locations. Maybe (in effect) passing --prefix=/opt/$P to configure? Smart, not really. Using portage to install packages that are outside of portage's control is kinda silly. If you want to do that, build it by hand or use a pre-compiled package such as a RPM or DEB from the author's site. But using portage lets you use emerge's dependency resolution, build system (ccache, distcc, etc), plus Gentoo patches and other fixes. With a rpm or deb you don't have the faintest clue what you're getting... Ed -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Proposal for advanced useflag-syntax
Enrico Weigelt [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 07 Aug 2006 16:18:21 +0200: Grandma wants to click, okay, so she should use graphical applications. She's not interested what sits behind, she just wants to have a buch of applications. And she also doesn't wann have anything to do with emerge and useflags. She just wants to have a choice between a bunch of end-user applications. That's the job of an Grandma-(sub-)distro. ... And it's not the job of Gentoo, which is targeted at those who enjoy having those extra knobs to twist, to get the package just the way they want. That's it's strength. If you want a distribution that's easy for someone not interested in command line emerge and learning about USE flags, there are other distributions, much stronger in those areas, while in turn being much weaker in the areas Gentoo excels in. Of course, it is also said that Gentoo is a meta-distribution. There are already a number of specially targeted distributions based on Gentoo, in part because Gentoo exposes the knobs to tweak, making it relatively easy to do so, and aim the result at a particular niche. It'd be perfectly acceptable to create another such Gentoo based distribution and hide all those knobs, replacing them with preconfigured choices, but that's not for Gentoo as a meta-distribution to do, but for downstream to do, should they decide to base their distribution on Gentoo. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SearchSecurity.com: Linux patch problems: Your distro may vary
As far as I'm aware the problem isn't the security team, but the reasons are: 1. slow/understaffed arch teams - and I suppose this is the biggest problem, as we need all security-wise supported¹ architectures stable, before a GLSA can be send out. 2. the amount of unmaintained stuff in the tree, no one cares for - see Sune's libwmf email 3. maintainer on vacation or for another reason inactive and didn't communicate that - no co-maintainer, no herd backing up, leaving everyone waiting. This ranking of course does neither say anything about the quality of the fixes, nor does the severity Secunia applies to an issue necessarily match the our's or other distribution security teams. Carsten [1] http://www.gentoo.org/security/en/vulnerability-policy.xml pgp03USjwtQMx.pgp Description: PGP signature
[gentoo-dev] Re: Re: Re: Masking practics
Enrico Weigelt [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 07 Aug 2006 15:01:57 +0200: My problem still seems unsolved (or did I miss something) ? You missed something. Lets say, if I've, installed foo-1.1, and it gets masked due some bug(s), but 1.0 isn't, I want to get informed with an big fat warning, *before* anything actually done, ie. [...] # WARNING: installed package foo-1.1 has been masked and would # be downgraded: # masking comment ... [...] That's precisely what emerge --pretend --verbose covers. Or, if you want the display with a question to continue or not, use --ask instead of --verbose. A good Gentoo user (read that as a good system administrator, because that's exactly what a Gentoo distribution user is in this context) will never run a straight fully automatic upgrade/downgrade, without knowing exactly what's going to be done, because that's foolhardy, as you correctly point out. They will always know what to expect, because they will have either used --pretend first, or will use --ask as a matter of course. Are you actually suggesting that you run emerge --update /blind/, /without/ having viewed the --pretend (or --ask) output to see what it's going to actually do, first? No /wonder/ you are having problems if so! That's why the --pretend and --ask switches are /there/! Use them for what they are intended for, and you'll no longer be troubled by downgrades without warning. Only /after/ you are comfortable that the command will do what you expect/want, do you run it without the --pretend, or say yes to the --ask. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
Duncan wrote: That's precisely what emerge --pretend --verbose covers. Or, if you want the display with a question to continue or not, use --ask instead of --verbose. I'm pretty sure you mean to use --ask instead of --pretend, not --verbose. -- Joshua Nichols Gentoo/Java - Project Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] implicit RDEPEND
On Sunday 06 August 2006 00:26, Mike Frysinger wrote: and i'm on the opposite side where implicit RDEPEND should be clean: Why? I for one consider explicit dependencies much more clean. If Portage at some point should distinct between dependencies defined in ebuilds and eclasses, we'd need a defined way to set eclass dependencies in ebuilds, so Portage actually can do the distiction, not breaking the tree. - eclass and ebuilds have their own sets of DEPEND/RDEPEND which do not in any way affect each other That's not true. We use and need the functionality to set dependencies in the ebuild which take effect in the eclass. Be it by setting a variable before inherit or by an eclass function called from within the ebuild - need-kde(), need-apache(), ... We can't source the eclass and have all its dependencies. Carsten pgp5cqj7dHWL2.pgp Description: PGP signature
[gentoo-dev] Re: SearchSecurity.com: Linux patch problems: Your distro may vary
Wolfram Schlich [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 07 Aug 2006 13:42:21 +0200: I just stumbled over an article from SearchSecurity.com which was linked to in a heise newsticker posting that tries to analyze how fast distributions react to security vulnerabilities: http://tinyurl.com/lplfb Quick chart: Rank DistroPoints/100 - -- 1. Ubuntu76 2. Fedora Core 70 3. Red Hat Enterprise Linux 63 4. Debian GNU/Linux 61 5. Mandriva Linux54 6. Gentoo Linux 39 7. Trustix Secure Linux 32 8. SUSE Linux Enterprise 32 9. Slackware Linux 30 Rank 6 out of 10 is not a great result -- at least we beat SUSE ;) I saw the same article and was similarly unhappy. One thing to note is that the timings, AFAIK, are based on the release of the security announcement for the distribution. With Gentoo, as others have pointed out, that means waiting for everybody to stabilize the update -- it's actually in the tree days/weeks before that. Realizing it's there for those who want it, well before the GLSA, is useful, altho it doesn't particularly help our standing or make us look that great. I do know however, that as a ~arch user, most of the time when I see a GLSA on the announce list, I check and I've had the fixed version installed for a week or more. For those who prefer stable, the above info can still be helpful. As long as you normally visit community sites such as LWN, which list security announcements when they become public (an article is created at the original announcement by the first distrib or the finder/upstream, then updated as the various distribs do their own announcements), the ebuilds are usually in the tree either at the moment of public announcement, or within 24 to 48 hours, best I can tell. There's nothing saying you have to wait for the GLSA or even for stable keywording. Once you see the announcement, check the tree for the version in question, or the changelog, as sometimes it's not a new version upstream so it's just a Gentoo -rX revision. You can then use package.keyword and etc. as appropriate, to get the security update, even if you normally use stable, days/weeks before the GLSA, and normally very soon after public announcement. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
* Thomas Cort [EMAIL PROTECTED] schrieb: On Mon, 7 Aug 2006 15:26:44 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: The bad thing is that those things don't get neither into the upstrem nor other distros. ^--- This should be a warning flag ---^ If other distros aren't doing it and upstream isn't doing it, then it may no be that great of an idea. Not really. Simply seems that no one else cares about the Debian patches, since they don't do enough publicity. They simply fix some problems at their side and are done with this. Same for other many distros. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Masking practics
* Alec Warner [EMAIL PROTECTED] schrieb: snip I would call you a horrible administrator since this: I run an update w/o knowing that it downgrades should NEVER happen. emerge -pv foo [ebuild UD] cat/foo-currentversion [downgraded-version] stuff Great. I have to explicitly compare the versions on each package. Not actually an great help. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
* Duncan [EMAIL PROTECTED] schrieb: snip # WARNING: installed package foo-1.1 has been masked and would # be downgraded: # masking comment ... [...] That's precisely what emerge --pretend --verbose covers. Or, if you want the display with a question to continue or not, use --ask instead of --verbose. Ah, emerge actually tells you that it's going to *downgrade* (not just printing out two version numbers and letting the user compare each packege's version number for its own) ? A good Gentoo user (read that as a good system administrator, because that's exactly what a Gentoo distribution user is in this context) will never run a straight fully automatic upgrade/downgrade, without knowing exactly what's going to be done, because that's foolhardy, as you correctly point out. They will always know what to expect, because they will have either used --pretend first, or will use --ask as a matter of course. Of course I always use -p, but having to look at each package's version numbers if it someday may want to downgrade. For such number comparison, humans are not the best processor, the computer is far much better for it. Why can't emerge just print out an fat warning if its going to downgrade ? Would save people from much, much trouble. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Beta versions should be slotable
* Noack, Sebastian [EMAIL PROTECTED] schrieb: snip I like to try bleeding edge beta versions. But I hate that if I will install for example the new firefox 2 beta via portage, it will unmerge the current stable version. I would prefer to have a stable version for daily work and the beta version for testing purposes at the same time on my system. Therefore I would propose to introduce a policy, which forces each ebuild with the suffix _alpha, _beta or _pre have to be slotable. Why not just putting alpha or beta packages in their own ebuild ? ie. firefox-BETA ? Those ebuilds should live in their own testing overlay, to keep the main tree smaller. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
Enrico Weigelt wrote: Why can't emerge just print out an fat warning if its going to downgrade ? Would save people from much, much trouble. # emerge -pv =coreutils-5.2.1-r7 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-apps/coreutils-5.2.1-r7 [5.94-r1] USE=-acl -build -nls -static 0 kB Total size of downloads: 0 kB See the little D? It's not big, it's not fat, but it's warning you. :) Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
* Simon Stelling [EMAIL PROTECTED] schrieb: Enrico Weigelt wrote: Oh hell, this can't be serious ! It is. It mixes up diffent things to one and just introduces new problems instead of solving anything. I could live with that, if it's for supporting different ABIs, but it obviously isn't. What sort of problems? An example backing up your claims would be very nice. + Additional complexity (slotting) is necessary, so additional changes of bugs. + Package maintainers have to both take care of slots *and* version number *ranges* + Different packages are treated as equal, produces confusion snip gtk1 and gtk2 are completely different packages, they're not compatible. So why should they be one package ? Just because they share some ideas and the name ?! Yes. Why not, after all? So, why don't you consider libxml and libxml2 equal packages ? snip For example, there are lots of packages requiring gtk1, other gtk2. As long as dependencies don't cope the slot cleanly, slotting is utterly useless. =x11-libs/gtk+-1.2* x11-libs/gtk+-2 do a decent job. As said: you have to take care of version *ranges*. Adds additional complexity. BTW: how do you enforce an minimum gtk1 version ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
* Luca Barbato [EMAIL PROTECTED] schrieb: Enrico Weigelt wrote: It mixes up diffent things to one and just introduces new problems instead of solving anything. I could live with that, if it's for supporting different ABIs, but it obviously isn't. No? In this case not - it's used to mix up two different packages. snip gtk1 and gtk2 are completely different packages, they're not compatible. So why should they be one package ? Just because they share some ideas and the name ?! Because gtk-2.xx is originated from gtk+-1.2.xx and you still have a common set of widget API ? The APIs are incompatible. For example, there are lots of packages requiring gtk1, other gtk2. As long as dependencies don't cope the slot cleanly, slotting is utterly useless. gtk-1 is deprecated, it will disappear sooner or later. Maybe, maybe not. That will take some time until all packages are rewritten from gtk1 to gtk2. BTW: an problem will go away by itself sooner or later isn't actually an good argumentation for such kind of problems. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: What sort of problems? An example backing up your claims would be very nice. + Additional complexity (slotting) is necessary, so additional changes of bugs. Oh please, this is so lame. That feature has been in existance for long enough to be proven useful and not faulty. The higher probability of problems is really not the best argument when discussing features that have been around for an incredible long time. + Package maintainers have to both take care of slots *and* version number *ranges* taking care takes you one line. I already gave you both dependency strings. Now guess what: If they were two packages, it would take you one line too! OMG! + Different packages are treated as equal, produces confusion Aside from that guy who opened bug 143063 [1] I have yet to see anybody who got confused by this behaviour. So, why don't you consider libxml and libxml2 equal packages ? Because that's the way upstream names them. As said: you have to take care of version *ranges*. Adds additional complexity. BTW: how do you enforce an minimum gtk1 version ? You know that this wouldn't even make sense, as - you've pointed it out so many times - the API is incompatible. So, I'm asking you one last time: Do you have any actual good reasons to not package things the way upstream does it? [1] http://bugs.gentoo.org/show_bug.cgi?id=143063 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: BTW: how do you enforce an minimum gtk1 version ? You know, a lot of these questions of yours could be answered clearly if you look at the ebuild documentation and developer manuals. http://devmanual.gentoo.org/ is a good start. :) Steve -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] media-gfx/xzgv
media-gfx/xzgv is masked pending removal due to a dead upstream. There are plenty of other image viewers out there which are maintained. -smithj -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: * Luca Barbato [EMAIL PROTECTED] schrieb: Enrico Weigelt wrote: It mixes up diffent things to one and just introduces new problems instead of solving anything. I could live with that, if it's for supporting different ABIs, but it obviously isn't. No? In this case not - it's used to mix up two different packages. gtk1 and gtk2 are completely different packages, they're not compatible. So why should they be one package ? Just because they share some ideas and the name ?! Because gtk-2.xx is originated from gtk+-1.2.xx and you still have a common set of widget API ? The APIs are incompatible. They are still the both evolutions of the same development tree, they are the same package, just different versions. If we changed the name of a package every time there was an API break, we would literally have thousands of packages in the tree that essentially do the same thing, just with different API's. According to this philosophy, we should change the name of the package every time net-misc/neon comes out with a new version, since it breaks API on every version. For example, there are lots of packages requiring gtk1, other gtk2. As long as dependencies don't cope the slot cleanly, slotting is utterly useless. gtk-1 is deprecated, it will disappear sooner or later. Maybe, maybe not. That will take some time until all packages are rewritten from gtk1 to gtk2. BTW: an problem will go away by itself sooner or later isn't actually an good argumentation for such kind of problems. There is no problem, gtk1 and gtk2 can be installed on the same system at the same time, and all packages in the tree have their dependencies set up to depends on whichever version of gtk they need. SLOTS take care of this quite well. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] PDA herd call for assistance
On Sat, Aug 05, 2006 at 05:31:27PM +0900, Chris White wrote: The PDA herd is pretty slim right now and the only active members are really liquidx and myself. That said I'm looking around for people that can help with confirmations/patches/etc. for app-pda packages. Plans are to hopefully pull some devs in from the process. That said, if you're interested give me a PM on IRC, or just send me an email. I'll offer a hand in a bit (after my wedding), as I use some of that stuff (syncing contacts between a Handspring and my cellphone). -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpYIe6tYGZuX.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Mon, 7 Aug 2006 15:26:44 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: * Noack, Sebastian [EMAIL PROTECTED] schrieb: snip Hey, come on. We're not Debian! Unnecessary and senseless splitting of packages is against the philosophy of Gentoo. I don't think we are not xyz is a good argumentation in technical discussions. At this point, Debian is actually doing good work. The bad thing is that those things don't get neither into the upstrem nor other distros. That's exactly what my OSS-QM project is for. *sigh*, if you want to use a source based Debian (as the combination of all your posts seems to indicate) then do so, stop trying to convert Gentoo into that. Or create your own private fork. I start to get *really* annoyed by your overall behavior in the last weeks, and I can tell you that takes quite a bit of effort. Really, re-evaluate your motivation for being on this list. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] gtk1 vs. gtk2
* Jean-Francois Gagnon Laporte [EMAIL PROTECTED] schrieb: On 8/7/06, Enrico Weigelt [EMAIL PROTECTED] wrote: * Simon Stelling [EMAIL PROTECTED] schrieb: You've already been told it's a non-issue, but here's why: http://devmanual.gentoo.org/general-concepts/slotting/index.html Oh hell, this can't be serious ! Yes it is and it's been in use for a Long Time Now(tm). It's not quite perfect but at least it's usable. In the current case, it's nothing more than an ugly hack for articially created non-problem. Just like the German Orthography reform ;-P snip This is useful for libraries which may have changed interfaces between versions ? for example, the gtk+ package can install both versions 1.2 and 2.6 in parallel. The assumption is wrong, gtk1 and gtk2 are incompatible versions of one library. They are completely different libraries, where one originally had been forked off the other one. Now they look similar, but are in no ways equal. snip For example, there are lots of packages requiring gtk1, other gtk2. As long as dependencies don't cope the slot cleanly, slotting is utterly useless. Ebuilds just have to depend upon =gtk-1.2* fex. Can I ask where did you find a case where portage didn't handle it cleanly ? Great, we need multiple dimensions (slots, upper version limit) to solve an artificial problem, which shouldn't exist at all. Also, file a bug on it if possible ? Yes, I'll file a bug on the whole gtk issue and all packages using this ugly hacks. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
* Steve Dibb [EMAIL PROTECTED] schrieb: snip [ebuild UD] sys-apps/coreutils-5.2.1-r7 [5.94-r1] USE=-acl -build -nls -static 0 kB Total size of downloads: 0 kB See the little D? It's not big, it's not fat, but it's warning you. :) Not actually an eye-catching. To be fair, do *you* actually look through *all* the emerge output if there's any D flag, without the risk of overlooking it someday ? Why can't emerge shout out some more verbose text ? Something really eye-catching ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
* Noack, Sebastian [EMAIL PROTECTED] schrieb: snip Is a need to have dozens of lines in your /etc/portage/package.use a simple approach? Maybe it is, if for you, simplicity means only less number of lines of code in the core of the application. But wasn't you the one who told me that quantity isn't the same like complexity? Well you could say that only source code and scripts contain logic and therefore numbers of lines in the config files doesn't means complexity, but what do I do by the config files of portage actually? I use them for example to instruct portage to enable useflag A but not for ebuild and useflag B but just for ebuild b. Do you claim that this is no logic? No, that's just quantity of information. Linear data, just like an list of addresses or phone numbers. There are no rules in it. The rules just exist in your mind, not in the portage system. And if you like to modelize them, it should be done separately on top of portage. Okay, let's assume for a while, we've got your additional rules in the portage system. Someone has to make the decision about which frontends to prefer over others. If it's you, then you'll be happy with that, since you'll most likely decide the way you like, but others may be very unhappy with your decisions. On the other hand, with anyone else making this decision, there's plenty risk, you'll be unhappy with his decision. I see big flamewars coming on that. Remember the sunrise affair(s) ? snip Rember: we started with the thesis, grandma wants graphical frontends whereever possible. This is in fact not an technical issue, instead a matter of personal taste, or lets say, an individual system configuration. Grandma wants to click, okay, so she should use graphical applications. She's not interested what sits behind, she just wants to have a buch of applications. And she also doesn't wann have anything to do with emerge and useflags. She just wants to have a choice between a bunch of end-user applications. That's the job of an Grandma-(sub-)distro. That was never the point where we started. That was just the point, you used to confuse this discussion. Maybe I missed something, but this was the first posting I read on that topic. The grandma scenario should just be a funny example for a requirement of such a advanced portage syntax I could really need on my own systems and I'm not female, but male and not 80 but 18 years old. ;) IMHO an bad chosen one, as I take such examples seriously. snip I know that my proposed syntax isn't a perfect solution. But I think the current state of portage isn't a perfect solution, too. And I hoped when I started this thread, that we will find together a good solution. IMHO, the problem isn't yet defined cleanly enough to have a chance on an good solution. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: Yes, I'll file a bug on the whole gtk issue and all packages using this ugly hacks. You can save your time. Really. And vastly more important, save our bug-wrangler's time. You've already filed a bug. It was closed as INVALID, and except for you nobody in this thread agreed with you. It won't get anywhere, because you're the only one pushing for that change. I can assure you that every single bug for every package you file will get marked as DUPLICATION of the first bug, which was closed as INVALID. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: The assumption is wrong, gtk1 and gtk2 are incompatible versions of one library. They are completely different libraries, where one originally had been forked off the other one. Now they look similar, but are in no ways equal. you don't know gtk. stop trolling. Great, we need multiple dimensions (slots, upper version limit) to solve an artificial problem, which shouldn't exist at all. there is no problem beside your emails, please unsubscribe, move to debian-dev and be happy with apt-build. Yes, I'll file a bug on the whole gtk issue and all packages using this ugly hacks. Good way to have your account suspendend. -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-security] SearchSecurity.com: Linux patch problems: Your distro may vary
Hi there, On Monday 07 August 2006 13:42, Wolfram Schlich wrote: Any comments or thoughts about this? Can we become better? Are we maybe better than the author pretends? Does the security team currently face serious problems that need to be solved, be it inside or outside the security team? I am just curious and would be glad to get some feedback :) I saw the article a few days back and here is a short summary of what I think about it: - I'm a bit disappointed with the result. - The Security Team is short on staff so we're not as speedy as we once was :-/ - The scores are not weighted to take severity into account. - No exact references are given to the vulnerabilities in question making it hard to check. - Secunia release dates are not the same as Gentoo release dates as Secunia seldom work during weekends. - Unstable uses usually get the fix hours or even days before the GLSA is issued. - My own non-scientific research indicates that we're not that bad compared to other community distributions like Debian (at least when you compare the latest GLSAs with the high severity rating). If you want to help out the Security Team and have some relevant skills please consult the link in my signature or send me a private email. -- Sune Kloppenborg Jeppesen (Jaervosz) Operational Manager Gentoo Linux Security Team http://security.gentoo.org pgpPl7ExaAuMy.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Masking practics
Enrico Weigelt wrote: Not actually an eye-catching. Ummm, D, as opposed to U... Yeah, that catches my eye. I am weird like that though. To be fair, do *you* actually look through *all* the emerge output if there's any D flag, without the risk of overlooking it someday ? Yes, honestly, I DO look at it - I wouldn't be much of a system administrator if I didn't. I *always* *always* run emerge -uDpv world when I do an update world - and not only that - but I *always* *always* run emerge -av packagename/world - I never ever blindly run an emerge - even if it is the same one I just ran a -p on. I dunno, guess I am just careful like that. Obviously, not everyone wants to be vigilant - but if you aren't - then you don't get to whine about it when it breaks. well actually I guess you do... Why can't emerge shout out some more verbose text ? Something really eye-catching ? Well, why not look into color.map - and as has been mentioned in this or other flags, read the finely written documentation - in fact, I know of other distros who use OUR documentation when pointing out how to do things to others on THEIR distros. Documentation isn't exactly written because the doc writers were bored. It was written so things aren't constantly repeated as have been over and over and over...infinity. Seriously, stop trying to be lazy and be a responsible system admin. cu No, cu! Steev -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
* Patrick McLean [EMAIL PROTECTED] schrieb: snip The APIs are incompatible. They are still the both evolutions of the same development tree, they are the same package, just different versions. Let's take an example the automobile world: The Mitsubishi Galant is an sucessor of the Lancer in the same way as gtk2 is sucessor of gtk1. Both car types are different, just sharing many concepts. If we changed the name of a package every time there was an API break, we would literally have thousands of packages in the tree that essentially do the same thing, just with different API's. Yes, but it would be much more cleaner. Everyone would see what actually happens. Now its hidden from the user, but not changing the fact that they're different. snip According to this philosophy, we should change the name of the package every time net-misc/neon comes out with a new version, since it breaks API on every version. If APIs break with every version (on non-alpha stuff), it's principle design failure. I tend to avoid such unstable packages. Thanks for the warning of neon, so I'll never even think of using it. BTW: an problem will go away by itself sooner or later isn't actually an good argumentation for such kind of problems. There is no problem, gtk1 and gtk2 can be installed on the same system at the same time, Of course. They're different packages. and all packages in the tree have their dependencies set up to depends on whichever version of gtk they need. SLOTS take care of this quite well. Yes, but package maintainers have to be much more carefully about these dependencies, as it would be necessary if we actually would treat them as different packages. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
On 8/7/06, Enrico Weigelt [EMAIL PROTECTED] wrote: To be fair, do *you* actually look through *all* the emerge output if there's any D flag, without the risk of overlooking it someday ? Um, sorry, but users *should* be looking at the output of --pretend to get an idea of what portage wants to do to their systems. And not just for the 'D' either. Why can't emerge shout out some more verbose text ? Something really eye-catching ? Please don't. Portage already has enough messages that try to be eye catching. I've only got two eyes after all... -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New(-ish) developer - Elfyn McBratney
It is my pleasure to introduce to you... the artist formerly known as... beu! Many will know Elfyn from his previous stint as a Gentoo developer. This time around, we have a understanding.. the sort that involves sleeping with fish and finding horseheads in your bed. Capish? He won't magically (well, I believe it was by magic, he is afterall an elf) disappear again and will be joining the kernel guys, the perl people and he'll be donning an apron and pink marigolds while helping out with the QA tree cleaner project. I of course am thrilled, not only did we (re-)gain another UK based dev, but a UK based dev with a great taste in music, a sick and twisted mind and the ability to put up with me singing. Welcome back, Elfyn! Christelxx -- $a=gentoo.org; Christel Dahlskjaer | [EMAIL PROTECTED] | www.$a Gentoo Developeress - User Relations, Developer Relations, Gentoo/MIPS, Gentoo/Alpha, PR, Events, Release Engineering -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: If we changed the name of a package every time there was an API break, we would literally have thousands of packages in the tree that essentially do the same thing, just with different API's. Yes, but it would be much more cleaner. Everyone would see what actually happens. Now its hidden from the user, but not changing the fact that they're different. __ ___ _ _ __ _ ___ ___ /_ /_ | | (_) | / / | | | | _/_ | |__ \ __ _| || |__| |_| |__ ___ / /_ _| |_| | ___| |_ __| |) | \ \/ / || |__| | | '_ \/ __| / / _` | __| |/ /_ _|__| | / / | || | | | | |_) \__ \/ / (_| | |_| |_|| |_ / /_ /_/\_\_||_| |_|_|_.__/|___/_/ \__, |\__|_|\_\|_(_)| __/ | |___/ Tell me, where is it actually hidden? I tend to avoid such unstable packages. Nice for you. We don't care. Thanks for the warning of neon, so I'll never even think of using it. Nice for you. We don't care. Of course. They're different packages. They have the same name. Different versions. That's how it is upstream and how it should be. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: According to this philosophy, we should change the name of the package every time net-misc/neon comes out with a new version, since it breaks API on every version. If APIs break with every version (on non-alpha stuff), it's principle design failure. I tend to avoid such unstable packages. Thanks for the warning of neon, so I'll never even think of using it. Don't forget to put sys-libs/db on your blacklist; also gtkhtml is a good candidate. And you probably shouldn't use gcc either, just to be on the safe side. ;) Which gets us to the point that you'd better have a look at other distros, which might more closely match your view. ;) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Endless frustrations again :(
big_snip Okay, you simply don't want to talk or even think about this issue. I won't waste more of my lifetime with it, and I won't let you do more acts of demotiviation. If you wouldn't have descrited my intensions this way and these personal attacks didn't happen, I would have set up my own overlay for this project and simply fix the problem. But obviously this isn't wanted here. All my other improvement efforts were simply ignored either or directly discredited, so they're also not wanted. You just want to remain in your traditional grid of thinking. You won't ever listen, so I'll let you stay there in peace. I'm now warned that I it's not wise to use gentoo for mission critical environments. I've got my own system builder for my mission critical needs, and I just tried gentoo as an quick solution for an uncritical server and some plain workstations. For that, it's still enough. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
On 8/7/06, Enrico Weigelt [EMAIL PROTECTED] wrote: The assumption is wrong, gtk1 and gtk2 are incompatible versions of one library. They are completely different libraries, where one originally had been forked off the other one. Now they look similar, but are in no ways equal. Have you actually visited http://www.gtk.org??! The 2.0 release announcement, the migration guide, the download page, pretty much everything makes it clear that gtk2 is the newer version of the _same_ library, not a completely different project. Indeed, even their CVS repository only has a gtk directory, not gtk1 and gtk2. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
* Steev Klimaszewski [EMAIL PROTECTED] schrieb: snip Obviously, not everyone wants to be vigilant - but if you aren't - then you don't get to whine about it when it breaks. well actually I guess you do... So, you don't have any intention to help people who don't have such an eagle-eye on single chars, even it could be easy ? snip Why can't emerge shout out some more verbose text ? Something really eye-catching ? Well, why not look into color.map - and as has been mentioned in this or Would be a first start. But doesnt help much in emails or monochrome terminals. Even piping to less kills colors. So I'll probably have no other chance than writing a frontend to emerge, parsing its output - hoping the output syntax remains the same for an sufficiant time :( cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: To be fair, do *you* actually look through *all* the emerge output if there's any D flag, without the risk of overlooking it someday ? Yes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE16tG6q4f+IV6B/wRApCbAJoC6r1YXAsp1SEcrVz0ODCQ1ngqVACfcrvg X0acTdrIGo9FN2l8aD7YmDo= =bsrK -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Monday 07 August 2006 22:09, Marius Mauch wrote: *sigh*, if you want to use a source based Debian (as the combination of all your posts seems to indicate) then do so, stop trying to convert Gentoo into that. Or create your own private fork. I start to get *really* annoyed by your overall behavior in the last weeks, and I can tell you that takes quite a bit of effort. Really, re-evaluate your motivation for being on this list. Marius I second this as should be clear from my earlier rant. Enrico should stop barking about how everything in gentoo is broken without having actually been active and built up a reputation. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpsZB8sBqVs8.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Masking practics
On Mon, 7 Aug 2006 23:01:45 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: Obviously, not everyone wants to be vigilant - but if you aren't - then you don't get to whine about it when it breaks. well actually I guess you do... So, you don't have any intention to help people who don't have such an eagle-eye on single chars, even it could be easy ? Users can help themselves. The D is in the exact same place (right before the ']') and in a different color (dark blue). You can use grep to find the downgrades: emerge -uD world -vp | grep D\] or grep D\] email.txt pgprcuY92v48z.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Masking practics
Enrico Weigelt wrote: * Steve Dibb [EMAIL PROTECTED] schrieb: See the little D? It's not big, it's not fat, but it's warning you. :) Not actually an eye-catching. To be fair, do *you* actually look through *all* the emerge output if there's any D flag, without the risk of overlooking it someday ? You don't have to look at it. Write your own little emerge wrapper script, let it amongst other things grep for UD, and let it howl when it finds it. Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Monday 07 August 2006 16:18, Enrico Weigelt wrote: I just want to keep things simple. We're talking about introducing new (additional) logic. This has to be maintained. And it doesn't actually *solve* the problem which is this discussion was started. Removing the stuff from the ebuild and maintaining two ebuilds that must be synchronized with eachother is complex. Rember: we started with the thesis, grandma wants graphical frontends whereever possible. This is in fact not an technical issue, instead a matter of personal taste, or lets say, an individual system configuration. Grandma wants to click, okay, so she should use graphical applications. She's not interested what sits behind, she just wants to have a buch of applications. And she also doesn't wann have anything to do with emerge and useflags. She just wants to have a choice between a bunch of end-user applications. That's the job of an Grandma-(sub-)distro. gentoo is not a grandma distro and does not try to be so. Okay, let's say we want to intruduce an meta-useflag for GUI (although having additional GUIs in the same package as the backend isn't what I consider clean design). If there's just *one* than it's easy - just an alias. But what's if we have more ? Who makes the decision, which one to take ? Based on what rules ? The council makes the decisions. Yes. For optional features. Additional programs aren't features of some other program, but additional programs. You should read up on your history. Useflags are as well for additional programs as for features. This is especially true when things should be kept together as they are tightly coupled. Ah, and this philosophy is more important than quality and maintainability ? You fail to see that what we do has quality and is certainly maintainable. pkg-config is a broken concept. Ah ? I consider it *very* clean. What could be easier than have an consistent database which *knows* what's installed on the system instead of having to run lots of esoteric tests which shall *guess* it somehow ?! The tests don't actually guess. The main problem though is that pkg-config encourages wrong linking. Linking should happen properly such that libraries link in their own dependencies, so that library users don't have to. If necessary, this database query can be intercepted easily. With the esoteric testing its very complicated or at least work intensive. There is nothing esoteric about checking for the existence of libfoo. Well, how would you get certain search pathes (-I, -L, ...) additional includes, dependency info for evrything but elf-so, ie .a ? The thing is you don't should not link the dependent libs of a dependency. That way you don't need to recompile if (say gtk was compiled with a new libpng version) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp5RxbtO9jVz.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Masking practics
On Mon, Aug 7, 2006 at 22:18:35 +0200, Enrico Weigelt wrote: * Alec Warner [EMAIL PROTECTED] schrieb: snip I would call you a horrible administrator since this: I run an update w/o knowing that it downgrades should NEVER happen. emerge -pv foo [ebuild UD] cat/foo-currentversion [downgraded-version] stuff Great. I have to explicitly compare the versions on each package. And what about the big blue 'D'? /Alexandre -- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgpgSBn4Uv7SJ.pgp Description: PGP signature
Re: [gentoo-dev] implicit RDEPEND
On Monday 07 August 2006 13:36, Carsten Lohrke wrote:
On Sunday 06 August 2006 00:26, Mike Frysinger wrote:
and i'm on the opposite side where implicit RDEPEND should be clean:
Why? I for one consider explicit dependencies much more clean.
i prefer to make the common behavior the default ... if more packages than not
will simply be doing:
RDEPEND=${DEPEND}
then typing that up a zillion times is a waste
- eclass and ebuilds have their own sets of DEPEND/RDEPEND which do not
in any way affect each other
That's not true. We use and need the functionality to set dependencies in
the ebuild which take effect in the eclass. Be it by setting a variable
before inherit or by an eclass function called from within the ebuild -
need-kde(), need-apache(), ...
you're looking at it wrong, what you need is not broken by my suggestion
[ebuild
set some vars to affect eclass
(eclass env sets up *DEPEND and saves them to $ECLASS_*DEPEND)
ebuild env sets up *DEPEND and saves them to *DEPEND]
-mike
pgpUERpqSuNuC.pgp
Description: PGP signature
[gentoo-dev] use.force as a complement to use.mask in profiles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've written a patch [1] that implements support for use.force and
package.use.force as originally described by Sven Wegener [2] over a year ago.
Basically, this feature is the exact opposite of use.mask and package.use.mask.
It forces USE flags to be enabled. The only way to disable these forced flags
is to mask them via use.mask/package.use.mask or to unforce them in the
profile stack. Users can unforce them via
/etc/portage/profile/{use.force,package.use.force} in the usual -flag way.
If use.force is abused, then it will make it difficult for users to disable
unwanted USE flags. Therefore, the only flags that should be forced are those
that should almost certainly be enabled. This is complementary to USE masking,
which should only be used to mask flags that should almost certainly be
disabled.
We've discussed this feature on the gentoo-portage-dev mailing list [3] and
people have expressed a desire to have the use.force feature. People also want
a way to enable default flags via IUSE, but that is a distinctly separate
feature. Considering that we have a proposed implementation for use.force,
shall we add support it now?
Zac
[1] http://dev.gentoo.org/~zmedico/portage/branches/2.1/patches/use.force.patch
[2] http://article.gmane.org/gmane.linux.gentoo.devel/28727
[3] http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2287
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE19O+/ejvha5XGaMRAsf2AJ4nC+m6Jp7FBMQYp3u4O+woSzoZxQCgk0tF
FMWOljyTePUjqD535K6AeWk=
=FwyG
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New(-ish) developer - Elfyn McBratney
On 07/08/06, Christel Dahlskjaer [EMAIL PROTECTED] wrote: It is my pleasure to introduce to you... the artist formerly known as... beu! Many will know Elfyn from his previous stint as a Gentoo developer. This time around, we have a understanding.. the sort that involves sleeping with fish and finding horseheads in your bed. Capish? He won't magically (well, I believe it was by magic, he is afterall an elf) disappear again and will be joining the kernel guys, the perl people and he'll be donning an apron and pink marigolds while helping out with the QA tree cleaner project. I of course am thrilled, not only did we (re-)gain another UK based dev, but a UK based dev with a great taste in music, a sick and twisted mind and the ability to put up with me singing. Welcome back, Elfyn! Christelxx -- $a=gentoo.org; Christel Dahlskjaer | [EMAIL PROTECTED] | www.$a Gentoo Developeress - User Relations, Developer Relations, Gentoo/MIPS, Gentoo/Alpha, PR, Events, Release Engineering -- gentoo-dev@gentoo.org mailing list Kneel in the presence of the dark master beuster, for the once apache guru has mutated and become master of perl and kernel and shall we reach forth or forever hold our peace. Thankyou -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico, Yes, but package maintainers have to be much more carefully about these dependencies, as it would be necessary if we actually would treat them as different packages. Have you asked the gentoo package maintainers how they feel on this subject, or are you supposing/guessing? -- Seemant Kulleen [EMAIL PROTECTED] Gentoo Foundation / Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Mon, 2006-08-07 at 15:48 +0200, Enrico Weigelt wrote: * Brian Harring [EMAIL PROTECTED] schrieb: ... Let's take a better example: nmap This package actually contains two completely different things: the portscanner tool and some gtk-based frontend. In fact the gtk useflag switches the second package. They're in fact two different applications (just one shipped as an subdir of another) and so should have two ebuilds. As a user, please dont do that. Fragmentation by splitting packages up is getting ridiculous. Yes, use a USE flag, but dont make it harder for users to find, build and install. My personal opinion is that whilst things like modular X are good for developers, they are not so good for users - particularly gentoo users. BillK -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Monday 07 August 2006 21:44, W.Kenworthy wrote: My personal opinion is that whilst things like modular X are good for developers, they are not so good for users - particularly gentoo users. we provide meta packages (X/kde/gnome/etc...) for the split packages so users can just emerge 1 package to get them all on one machine i like to run kde so the meta packages are a godsend ... yet on another machine, i only want k3b/kmail and nothing else so the split packages too are a godsend :) -mike pgpzBEKsiDFOE.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for advanced useflag-syntax
W.Kenworthy wrote: My personal opinion is that whilst things like modular X are good for developers, they are not so good for users - particularly gentoo users. Definitely not true. The X.Org 7.1 release shared the vast majority of packages with 7.0, so there were very few upgrades -- just a few drivers and the server. In the monolithic world, you would've needed to rebuild the whole thing for that. Installing it is a one-time cost, upgrading goes on forever. And the security updates that already occurred proved modularization well worth the effort -- often, just a single package (the server) needed an update. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Zac Medico wrote:
I've written a patch [1] that implements support for use.force and package.use.force as originally
described by Sven Wegener [2] over a year ago. Basically, this feature is the exact opposite of
use.mask and package.use.mask. It forces USE flags to be enabled. The only way to disable these
forced flags is to mask them via use.mask/package.use.mask or to unforce them in the
profile stack. Users can unforce them via /etc/portage/profile/{use.force,package.use.force} in
the usual -flag way.
If use.force is abused, then it will make it difficult for users to disable
unwanted USE flags. Therefore, the only flags that should be forced are those
that should almost certainly be enabled. This is complementary to USE masking,
which should only be used to mask flags that should almost certainly be
disabled.
We've discussed this feature on the gentoo-portage-dev mailing list [3] and
people have expressed a desire to have the use.force feature. People also want
a way to enable default flags via IUSE, but that is a distinctly separate
feature. Considering that we have a proposed implementation for use.force,
shall we add support it now?
I read the portage-dev discussion, and I'm still not seeing how this is
superior to make.defaults. If you want to be enabling local USE flags by
default, this is no less of a hack than that is -- what's truly needed
is some way to set per-package defaults.
The only valid use I can see is things like the architecture, libc, and
so forth. And it seems like there ought to be better solutions to this
than adding another hack on top of USE.
BTW your mail was really difficult to reply to, since it didn't have any
line wrapping.
Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New(-ish) developer - Elfyn McBratney
Christel Dahlskjaer wrote: I of course am thrilled, not only did we (re-)gain another UK based dev, but a UK based dev with a great taste in music, a sick and twisted mind and the ability to put up with me singing. Welcome back, Elfyn! Awesome. Welcome aboard, Elfyn! -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] mulltiib cruft: /emul
someone remind me why our emul packages install in some obscure directory tree rooted in /emul if we moved these things to the standard lib32 dirs, it would certainly ease the pain of people doing multilib building -mike pgp0iUxwqWpVd.pgp Description: PGP signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: I read the portage-dev discussion, and I'm still not seeing how this is superior to make.defaults. The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If you want to be enabling local USE flags by default, this is no less of a hack than that is -- what's truly needed is some way to set per-package defaults. That's distinctly separate feature that is also needed. The only valid use I can see is things like the architecture, libc, and so forth. And it seems like there ought to be better solutions to this than adding another hack on top of USE. The use.force feature is complementary to use.mask. It's exactly the same concept, but inverted. BTW your mail was really difficult to reply to, since it didn't have any line wrapping. Sorry about that. I don't like forced line wrapping but I understand that many email clients don't behave very well without it. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE2AWq/ejvha5XGaMRAkxCAKDeBiDdrPFoUxMpSbin0OAunF0ZDwCgmnB5 n84YnXuED/W01dTO4vl5nyc= =cGVg -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] multilib curft: env.d/04multiilb
why god why do we have this file ? it pollutes ld.so.conf and makes me so angry -mike pgpOFUoFK4Ze9.pgp Description: PGP signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Zac Medico wrote: The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If they were so extremely important then they would not be optional, and hence not even be USE flags at all, no? Or am I missing something? -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Mon, Aug 07, 2006 at 08:31:55PM -0700, Zac Medico wrote: Donnie Berkholz wrote: I read the portage-dev discussion, and I'm still not seeing how this is superior to make.defaults. The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. Name a few please. I know of selinux, and multilib- all that are effectively features, and exist in the use conditional namespace because they unfortunately straddle both (same issue with FEATURES=test). So... two flags I can think of, and it requires recording the setting in multiple spots (features, use, and now use.force). How is this improving it really? It blocks people from disabling automatic pulling in of selinux policies, presumably trying to prevent them *accidentally* disabling it. If the target is those flags... this patch doesn't really cut it either. Said patch is actually atom - flags forcing, not global forcing. The original request (url to sven's discussion) was actual globally forced flags, not per package- would have to specify every single consumer of selinux flag (for example) to get the same. If you want to be enabling local USE flags by default, this is no less of a hack than that is -- what's truly needed is some way to set per-package defaults. That's distinctly separate feature that is also needed. What you've implemented is just that however; the only difference is that it's forced rather then 'default' configuration state. The only valid use I can see is things like the architecture, libc, and so forth. And it seems like there ought to be better solutions to this than adding another hack on top of USE. The use.force feature is complementary to use.mask. It's exactly the same concept, but inverted. And both files _should_ be implemented via use deps. I've yet to see the exit strategy for these files when use deps comes about also; when either portage grows it, or portage gets replaced, going to basically have one file that is non use dep restrictions, and one that allows use deps. Why again are these two files being added? Use use dep syntax in package.mask, no exit strategy needed- just requires splitting the deps out from there instead of reading two seperate files. ~harring pgpXsV5wTrwg3.pgp Description: PGP signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Peter Gordon wrote: Zac Medico wrote: The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If they were so extremely important then they would not be optional, and hence not even be USE flags at all, no? Or am I missing something? Hmm... I set out to build a system recently (since 2006.0) with USE=-*, just to see if I could. After borking python a couple of times (you know how it is ;)), I was prevented from completing system by a couple of ebuilds failing on not having c++ available. One was bison, which failed on one of its examples rather than on the program itself. I can't remember what the other package was, but it was a C-only package (yacc maybe? or did it begin with a 'g'?) that failed in configure - I remember wondering where the Removing useless C++ checks message was when I needed it. Around about then I stopped having spare time, so I never filed bugs or investigated further. My point, now that I've bored you all with a long story, is that if you're careful about it, no USE flag is *truly* required, at least for a working system. Sure, some are highly recommended - but isn't that what defaults are for? :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Mon, Aug 07, 2006 at 09:57:39PM -0700, Ryan Tandy wrote: Peter Gordon wrote: Zac Medico wrote: The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If they were so extremely important then they would not be optional, and hence not even be USE flags at all, no? Or am I missing something? Hmm... I set out to build a system recently (since 2006.0) with USE=-*, just to see if I could. After borking python a couple of times (you know how it is ;)), I was prevented from completing system by a couple of ebuilds failing on not having c++ available. Question your method of bootstraping then- note that for gcc it's nocxx, not cxx. Meaning, USE=nocxx _disables_ building cxx; this is why default IUSE is requested, to kill off the 'no' (and it's seperate from my point)- c++ related failures there would be due to either A) bootstrap script was stupid, wasn't working around portage correctly B) portage was dumber then the norm, and was screwing up dependency ordering (woot) ;) C) user intervention somehow screwd up the bootstrapping ;) My point, now that I've bored you all with a long story, is that if you're careful about it, no USE flag is *truly* required, at least for a working system. Sure, some are highly recommended - but isn't that what defaults are for? :) Better point would be that the dependencies in use aren't actually representative- if it requires c++ from gcc, it should be a use dep (something portage doesn't yet support). *Forcing* it to always have c++ on isn't much better either. ~harring pgpfRxgHmDTIy.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: You're asking on the wrong ml. Profile monkeying really should include a run through of -dev, *especially* something like that that's going to be a pita to turn off when folks start abusing it... I'm just running it by the smaller audience first to get some feedback. Prefer default IUSE myself, but the point this should get a run through on dev stands ~harring Default IUSE would be nice, but maybe people want something at the profile level as well. We'll see... Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE1th9/ejvha5XGaMRAvcZAJ4gja3eYQ0t+stCx9Kp4YgJcK8piACgwifc ZEy7Qj60Cc9fQQnkaqd/zQg= =PM17 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Brian Harring wrote: You're asking on the wrong ml. Profile monkeying really should include a run through of -dev, *especially* something like that that's going to be a pita to turn off when folks start abusing it... Make sure you explicitly state that one *must not* force a flag simply because a build breaks with USE=-foo. Other than that, I'm for it. It will make my job easier :) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
On Sun, 2006-08-06 at 22:08 +0100, Paul Bredbury wrote: Other cases would want it to return TRUE. Got an example of those? I expect to be able to show that they're incorrect. Sorry to keep this alive. Example: subversion.eclass has if built_with_use dev-util/subversion nowebdav; then die need webdav support in subversion ... Clearly, where an ebuild requires that a package be merged *without* a USE flag set, a FALSE return from built_with_use is expected to indicate that that package was merged with that USE flag unset. Looking at this logically, you're interpreting built_with_use as the Russell definite designator: built_with_use (A, Fl) := Fl set_on (i P. P matches A) == Ex P. (All P'. (P' matches A = P' = P) ^ Fl set_on P) where A denotes an atom, Fl a flag, P, P' a package. Yes, the Russell definite designator has value FALSE if it lacks a referent; however there is no need for built_with_use to behave as the definite designator, since we have a trinary logic (TRUE, FALSE, die) available. The big problem with the Russell definite designator is that it is not self-dual under negation (and its dual under negation is not useful); a trinary definite designator /is/ self-dual. (That is, built_with_use app-foo/bar shiney is equivalent to ! built_with_use app-foo/bar -shiney. Which is what ebuild authors want.) HTH, Ed -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
if built_with_use dev-util/subversion nowebdav; then So Portage needs an end to USE flags whose first 2 characters are 'no' day, in order to keep its complexity bearable. Which is already known, in the dev manual (whose URL I'm too lazy to look up right now). The big problem with the Russell definite designator is that it is not self-dual under negation (and its dual under negation is not useful); a trinary definite designator /is/ self-dual. That's useful info in a school exam. The flaw is, this is not a maths quiz set by a university professor (I went through all that at uni ~13 years ago). It's a computer program. Run by people. Who expect it to make sense. These people couldn't care less whether it's self-dual under negation. What they care about is whether it gives the right answer, or the opposite of the right answer (or equally worse, falls over in a big heap) when the right answer should be obvious to it (which is what my patches do, although this fact has so far been glossed over). The attractive elegance of logical dualism is *not* an excuse for programs falling over in a big heap when the correct answer in certain circumstances (bug #139693) is obvious. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Zac Medico wrote:
Users can unforce them via /etc/portage/profile/{use.force,package.use.force}
in the usual -flag way.
Why new files? Why isn't this just pushed into the use stacking order
over-ridable by the user (default USE flags, and not forcing)?
Then they can over-ride it in package.use just like they do now?
Brian, default USE in IUSE is not a backwards compatable change and this
is easier ;)
/me runs
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Edward Catmur wrote: If the package is installed through package.provided, then I agree with the *current* Portage behaviour of assuming that all USE flags are on. Ya can't blame me for that. It's currently the only sensible choice. (Funnily enough, no-one has suggested dying as an option for this). I would. Pending a proper resolution (USE data in package.provided), users can set USE in vdb. First, having users poke around in vdb is a very bad idea. Doing the wrong thing in there can cause all kinds of weird b0rkage. Second, does portage even consult vdb for a package in package.provided? package.provided was created to *replace* the act of creating a dummy vdb entry (I think that's how it was done, anyway) to fool portage into thinking a package was installed. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Checking for a package that isn't either a direct or indirect dependency is plain wrong. package.provided is not supported - it's the users fault, if he insists to sidestep Portage. There is no valid case for your construct. With regards to QA, it wouldn't be wrong to have a better solution, but given that built_with_use() is itself only a workaroud for still not having use dependencies, it's a bit pointless. Carsten pgpIcKouSDHXT.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
Zac Medico wrote:
Users can unforce them via
/etc/portage/profile/{use.force,package.use.force} in the usual -flag way.
Why new files? Why isn't this just pushed into the use stacking order
over-ridable by the user (default USE flags, and not forcing)?
Much like use.mask, which is for flags that almost certainly should _not_ be
enabled, use.force is for flags that almost certainly _should_ enable.
Then they can over-ride it in package.use just like they do now?
Again, it's akin to use.mask, and protects the user from accidentally doing
something that they almost certainly shouldn't do (though they have the option
to override it if absolutely necessary).
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE153K/ejvha5XGaMRAoGnAJ9sCh9OMu064tLwScuyQdBvbHiwKwCg3RBv
4feX6Eg2jZen/TiQfhdzr6o=
=j/9F
-END PGP SIGNATURE-
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Zac Medico wrote:
Alec Warner wrote:
Zac Medico wrote:
Users can unforce them via
/etc/portage/profile/{use.force,package.use.force} in the usual -flag
way.
Why new files? Why isn't this just pushed into the use stacking order
over-ridable by the user (default USE flags, and not forcing)?
Much like use.mask, which is for flags that almost certainly should _not_ be
enabled, use.force is for flags that almost certainly _should_ enable.
Then they can over-ride it in package.use just like they do now?
Again, it's akin to use.mask, and protects the user from accidentally doing
something that they almost certainly shouldn't do (though they have the
option to override it if absolutely necessary).
Zac
hrm, so not default use flags then.
--
gentoo-portage-dev@gentoo.org mailing list
