Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On Wed, Oct 28, 2009 at 4:51 AM, Petteri Räty betelge...@gentoo.org wrote: Mike Frysinger wrote: On Tuesday 27 October 2009 14:46:31 Petteri Räty wrote: Normally old versions are not kept around as already said if you read the thread. normal is not the same thing as always. unless you're the maintainer, you have no idea whether old versions are kept there on purpose. ive had people delete older versions of packages on me simply because they made this invalid assumption without talking to the maintainer. the rest of the thread is irrelevant as this point was not made. Yes I have no idea. That's why I asked on gentoo-dev-announce for maintainers to tell me if they are kept on purpose so the point was made already at the very start. Regards, Petteri I see several of my packages on there as well and there's absolutely no way you're culling them since they have a definite use since you're script clearly failed to take into consideration various profiles and SLOTs. Biggest reason that my packages still use built_with_use is the lack of the --missing option for EAPI=2. -- Doug Goldstein
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
Mike Frysinger wrote: On Tuesday 27 October 2009 14:46:31 Petteri Räty wrote: Normally old versions are not kept around as already said if you read the thread. normal is not the same thing as always. unless you're the maintainer, you have no idea whether old versions are kept there on purpose. ive had people delete older versions of packages on me simply because they made this invalid assumption without talking to the maintainer. the rest of the thread is irrelevant as this point was not made. Yes I have no idea. That's why I asked on gentoo-dev-announce for maintainers to tell me if they are kept on purpose so the point was made already at the very start. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On Wed, 28 Oct 2009 11:51:34 +0200 Petteri Räty betelge...@gentoo.org wrote: Mike Frysinger wrote: On Tuesday 27 October 2009 14:46:31 Petteri Räty wrote: Normally old versions are not kept around as already said if you read the thread. normal is not the same thing as always. unless you're the maintainer, you have no idea whether old versions are kept there on purpose. ive had people delete older versions of packages on me simply because they made this invalid assumption without talking to the maintainer. the rest of the thread is irrelevant as this point was not made. Yes I have no idea. That's why I asked on gentoo-dev-announce for maintainers to tell me if they are kept on purpose so the point was made already at the very start. Still, it has already been stated but: please file bugs! A big tracker would probably be messy, one bug / herd or category could be better. You did file some bugs at some point, where I was in the assigned herd and did proceed quickly I think. Why did you stop? Some were just straight removal, some did need some other removal in order to be clean (this may be due to the fact that packages didnt work with latest versions but didn't have restricted deps on the package that would have to be removed). I am not following -dev very carefully and am too lazy to dig in a list posted on -dev-announce to find out if I need to do something or not. A bug makes that easy to track and is the usual way of getting ebuild changes done in the tree. We rant on users who report bugs on -dev, I'm afraid the the same applies to developers :) Also, remark that your script is flawed, I see some freebsd stuff in your list which are certainly the best visible version on some profiles. Again, this will be better tracked in a bug. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On Tuesday 27 October 2009 14:46:31 Petteri Räty wrote: Normally old versions are not kept around as already said if you read the thread. normal is not the same thing as always. unless you're the maintainer, you have no idea whether old versions are kept there on purpose. ive had people delete older versions of packages on me simply because they made this invalid assumption without talking to the maintainer. the rest of the thread is irrelevant as this point was not made. a quick check of your list shows wine/uclibc shouldnt be blindly culled. Live ebuilds shouldn't really have been in the original list with my intended logic. For them I will usually just migrate them to EAPI 2 like with other packages we have been touching. OK Using a tracker bug makes sense if you expect some action from individual maintainers which is not the case here as they can just leave the job to people nuking built_with_use like me. i dont plan on fixing my ebuilds soonish since this isnt a terribly important issue, but they'll get fixed at some point -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
Patrick Lauer wrote: And that's with all the forced migrations for features like use-deps or the removal of built_with_use. So unless there's some strongly needed features there's no need for it. I can't remember any feature in the EAPI 3 list that really looked useful to me, so not adding it now now now doesn't bother me at all. Just causes more confusion for no real benefit. So who cares if it is delayed by a few timeunits, there's much more important stuff to do. Here's two features that by themselves are important enough to get EAPI 3 implemented. Using pkg_pretend it should be possible to eliminate expected dies from build time and as such improving user experience. An example is two use flags that conflict with each other. Use dependency defaults make the life of ebuild writers easier as you don't need to be careful with version restrictions any more if you have a case where something has been on by default and then becomes a use flag for example. This should eliminate cases like causing glibc downgrade in the depgraph by being careless. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
Tomáš Chvátal wrote: On čtvrtek 08 Říjen 2009, 23:34:10 Petteri Räty wrote: Even this is wrong because: Hi ... betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE nls For most packages old versions are not kept around so just doing =cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI 3 in the far future. This is not exactly nice of you. And taking in account that you are actualy the council member it makes me feel not entirely happy. If we just simply take look onto this: http://cia.vc/stats/author/zmedico/ we can count that Zac commit something into portage every 3 hours. It does not look entirely like slacking... So you are basicaly proposing that maintaining the current codebase and improving what we already have is less important than providing new features, that is also not good. I am not suggesting that the work Zac does is worthless. I am saying that implementing EAPI 3 is not a colossal amount of work and if it was a priority to him it would have already been implemented. If he feels offended by my original comment, I have no problem apologizing to him. Not having EAPI 3 implemented in general is not his fault as many of us have the needed skills to start helping on the Portage code base. The reality just is that he is the most likely person to implement it and as such a very important factor on when it happens. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
Marijn Schouten (hkBst) wrote: Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: I have some ebuilds on the list: plt-scheme, stklos, lilypond. I usually clean up unused ebuilds some time after a new version has gone stable. Anyway my question is: what is the point of removing unused versions in the proposed manner? If the newer version is not ported to EAPI 2 and also uses built_with_use what do we gain? Even if it is already ported, do we gain anything by the propsed removal? Are all unused ebuilds evil? It saves my time when removing built_with_use from packages that still have active versions using it. Many packages are also unmaintained so the versions with built_with_use don't get removed without doing something like this. If built_with_use is to be eliminated from the tree I propose that effort is directed towards porting and stabling ebuilds that still use it. After the stable version has begun using EAPI 2 use deps, then all uses of built_with_use in other versions can be considered obsolete and those ebuilds can be removed in one fell sweep if need be. It will be eliminated eventually. I am in the process of doing so but as you can see from the numbers it takes quite a lot of work to get rid of them. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
Stelian Ionescu wrote: On Tue, 2009-09-29 at 16:32 +0300, Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: built_with_use shouldn't be removed until EAPI=3 gets approved because currently there's no good way to emulate --missing true|false|die yes, I can use something like this in sbcl: || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) but not all its use cases may be this simple Even this is wrong because: betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE nls For most packages old versions are not kept around so just doing =cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI 3 in the far future. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On Thu, Oct 8, 2009 at 4:34 PM, Petteri Räty betelge...@gentoo.org wrote: Stelian Ionescu wrote: On Tue, 2009-09-29 at 16:32 +0300, Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: built_with_use shouldn't be removed until EAPI=3 gets approved because currently there's no good way to emulate --missing true|false|die yes, I can use something like this in sbcl: || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) but not all its use cases may be this simple Even this is wrong because: betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE nls For most packages old versions are not kept around so just doing =cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI Comments like these are not acceptable. Zac works his tail off on portage. Please refrain from such comments in the future. -Jeremy 3 in the far future. Regards, Petteri
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
Jeremy Olexa wrote: On Thu, Oct 8, 2009 at 4:34 PM, Petteri Räty betelge...@gentoo.org wrote: Stelian Ionescu wrote: On Tue, 2009-09-29 at 16:32 +0300, Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: built_with_use shouldn't be removed until EAPI=3 gets approved because currently there's no good way to emulate --missing true|false|die yes, I can use something like this in sbcl: || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) but not all its use cases may be this simple Even this is wrong because: betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE nls For most packages old versions are not kept around so just doing =cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI Comments like these are not acceptable. Zac works his tail off on portage. Please refrain from such comments in the future. -Jeremy He has said himself that he is not especially interested in implementing EAPI 3 so slack at least to me seems like a good term. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On čtvrtek 08 Říjen 2009, 23:34:10 Petteri Räty wrote: Even this is wrong because: Hi ... betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE nls For most packages old versions are not kept around so just doing =cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI 3 in the far future. This is not exactly nice of you. And taking in account that you are actualy the council member it makes me feel not entirely happy. If we just simply take look onto this: http://cia.vc/stats/author/zmedico/ we can count that Zac commit something into portage every 3 hours. It does not look entirely like slacking... So you are basicaly proposing that maintaining the current codebase and improving what we already have is less important than providing new features, that is also not good. Just my 2 cents Tomas
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On Friday 09 October 2009 00:22:26 Petteri Räty wrote: across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI Comments like these are not acceptable. Zac works his tail off on portage. Please refrain from such comments in the future. -Jeremy He has said himself that he is not especially interested in implementing EAPI 3 so slack at least to me seems like a good term. I'm not sold on it either. Most devs barely know the difference between different EAPIs (just extrapolating from the many questions I see e.g. on IRC) (and I think they shouldn't have to know because we should be using one EAPI only, but that's just my random opinion) Most ebuilds are still EAPI0 - rough count gives me: EAPI 0 - 19654 EAPI 1 - 1651 EAPI 2 - 5497 And that's with all the forced migrations for features like use-deps or the removal of built_with_use. So unless there's some strongly needed features there's no need for it. I can't remember any feature in the EAPI 3 list that really looked useful to me, so not adding it now now now doesn't bother me at all. Just causes more confusion for no real benefit. So who cares if it is delayed by a few timeunits, there's much more important stuff to do.
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: I have some ebuilds on the list: plt-scheme, stklos, lilypond. I usually clean up unused ebuilds some time after a new version has gone stable. Anyway my question is: what is the point of removing unused versions in the proposed manner? If the newer version is not ported to EAPI 2 and also uses built_with_use what do we gain? Even if it is already ported, do we gain anything by the propsed removal? Are all unused ebuilds evil? If built_with_use is to be eliminated from the tree I propose that effort is directed towards porting and stabling ebuilds that still use it. After the stable version has begun using EAPI 2 use deps, then all uses of built_with_use in other versions can be considered obsolete and those ebuilds can be removed in one fell sweep if need be. Marijn - -- If you cannot read my mind, then listen to what I say. Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrMedEACgkQp/VmCx0OL2zCEACeK0xQpwjf1UPGVWz4izqD/km6 6ZoAn2BQAcS8Ir0NKAkaH5ui1U/cN1V3 =rmtP -END PGP SIGNATURE-
[gentoo-dev] Unused ebuild built_with_use cleanup
I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: betelge...@pena /usr/portage $ grep --include *.ebuild built_with_use -r . | wc -l; 923 betelge...@pena ~/bin $ wc -l ebuilds_to_nuke.txt 317 ebuilds_to_nuke.txt Regards, Petteri #!/usr/bin/ruby require 'Paludis' include Paludis env = EnvironmentFactory.instance.create('') require 'systemu' status, stdout, stderr = systemu 'adjutrix -U --repository-dir /usr/portage/' for line in stdout next unless line.include?('/') spec = = + line.strip id = env[Selection::RequireExactlyOne.new( Generator::Matches.new(Paludis::parse_user_package_dep_spec(spec, env, []), []))].first ebuild = id['EBUILD'].value File.open(ebuild) do |f| puts ebuild if f.any? {|line| line.include?('built_with_use') } end end /usr/portage/app-admin/diradm/diradm-2.9.5.ebuild /usr/portage/app-admin/gnome-system-tools/gnome-system-tools-2.22.1-r1.ebuild /usr/portage/app-admin/moodss/moodss-20.2.ebuild /usr/portage/app-emulation/crossover-office-pro-bin/crossover-office-pro-bin-4.2.ebuild /usr/portage/app-emulation/emul-linux-x86-qtlibs/emul-linux-x86-qtlibs-20080316.ebuild /usr/portage/app-emulation/emul-linux-x86-qtlibs/emul-linux-x86-qtlibs-20071114-r2.ebuild /usr/portage/app-emulation/virtualbox-ose/virtualbox-ose-.ebuild /usr/portage/app-emulation/virtualbox-ose/virtualbox-ose-1.6.6-r1.ebuild /usr/portage/app-emulation/vmware-player/vmware-player-2.5.2.156735.ebuild /usr/portage/app-emulation/vmware-player/vmware-player-2.5.1.126130.ebuild /usr/portage/app-emulation/vmware-workstation/vmware-workstation-6.5.2.156735.ebuild /usr/portage/app-emulation/vmware-workstation/vmware-workstation-6.5.1.126130.ebuild /usr/portage/app-emulation/wine/wine-1.1.11.ebuild /usr/portage/app-emulation/wine/wine-1.1.10.ebuild /usr/portage/app-emulation/wine/wine-1.1.9.ebuild /usr/portage/app-emulation/wine/wine-1.1.8.ebuild /usr/portage/app-emulation/wine/wine-1.1.7.ebuild /usr/portage/app-emulation/wine/wine-1.1.6.ebuild /usr/portage/app-emulation/wine/wine-1.1.5.ebuild /usr/portage/app-emulation/wine/wine-1.1.4.ebuild /usr/portage/app-emulation/wine/wine-1.1.3.ebuild /usr/portage/app-emulation/wine/wine-1.1.2.ebuild /usr/portage/app-emulation/wine/wine-1.1.1.ebuild /usr/portage/app-emulation/wine/wine-1.1.0.ebuild /usr/portage/app-emulation/wine/wine-1.0.1.ebuild /usr/portage/app-emulation/wine/wine-1.0.ebuild /usr/portage/app-emulation/xen-tools/xen-tools-3.4.1.ebuild /usr/portage/app-emulation/xen-tools/xen-tools-3.4.0-r1.ebuild /usr/portage/app-emulation/xen-tools/xen-tools-3.4.0.ebuild /usr/portage/app-emulation/xen-tools/xen-tools-3.3.1.ebuild /usr/portage/app-emulation/xen-tools/xen-tools-3.3.0.ebuild /usr/portage/app-emulation/xen-tools/xen-tools-3.2.1.ebuild /usr/portage/app-emulation/xen-tools/xen-tools-3.1.3-r1.ebuild /usr/portage/app-emulation/xen-tools/xen-tools-3.1.3.ebuild /usr/portage/app-i18n/scim-bridge/scim-bridge-0.4.15.2.ebuild /usr/portage/app-i18n/scim-bridge/scim-bridge-0.4.15-r3.ebuild /usr/portage/app-i18n/uim/uim-1.4.2.ebuild /usr/portage/app-office/abiword/abiword-2.6.6.ebuild /usr/portage/app-office/abiword/abiword-2.6.5.ebuild /usr/portage/app-office/kmymoney2/kmymoney2-0.8.9.ebuild /usr/portage/app-office/krita/krita-1.6.3.ebuild