[gentoo-dev] make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )
* Robin H. Johnson (robbat2) robb...@gentoo.org: 1.1 app-arch/hardlink/hardlink-0.1.1.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1content-type=text/plain src_install() { emake DESTDIR=${D} install ^ || die } 1.1 app-arch/duff/duff-0.4.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1content-type=text/plain src_install() { emake DESTDIR=${D} install ^ || die dodoc AUTHORS ChangeLog HACKING NEWS README* TODO } An imprecise search (/make .*install$/) revealed another 200 packages: http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt Let it die before replacing a working package with a broken one. Thanks
[gentoo-dev] eapi files and profiles
So I was told Council needs to approve inheritance of eapi files from parent profiles? I'm not sure why, because we shouldn't have any files in default/linux/ which was decided long ago when the new profiles was introduced... gentoo-x86/profiles/default/linux $ find ./ -name eapi | wc -l 63 That's 63 duplicated files. We should only have one releases/10.0/eapi file, and others wouldn't be required as it would cover all the 10.0 profiles. See, http://bugs.gentoo.org/288320 Can we get a decision on this soon, so we can drop the duplication for 10.1 (or whatever the name for next profile set will be called) ?
Re: [gentoo-dev] eapi files and profiles
On Fri, 23 Oct 2009, Samuli Suominen wrote: So I was told Council needs to approve inheritance of eapi files from parent profiles? Doesn't http://bugs.gentoo.org/288320#c7 cover this? Why would you need explicit inheritance? And which EAPI should be taken, if you have more than one parent profile? (All of them? Can a profile have multiple EAPIs?) Ulrich
Re: [gentoo-dev] make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )
On Fri, 23 Oct 2009 09:28:47 +0200 Torsten Veller ml...@veller.net wrote: * Robin H. Johnson (robbat2) robb...@gentoo.org: 1.1 app-arch/hardlink/hardlink-0.1.1.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1content-type=text/plain src_install() { emake DESTDIR=${D} install ^ || die } 1.1 app-arch/duff/duff-0.4.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1content-type=text/plain src_install() { emake DESTDIR=${D} install ^ || die dodoc AUTHORS ChangeLog HACKING NEWS README* TODO } An imprecise search (/make .*install$/) revealed another 200 packages: http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt Let it die before replacing a working package with a broken one. Thanks maintainer-needed done Detail: app-dicts/qvortaro/qvortaro-0.3.0.ebuild app-dicts/qvortaro/qvortaro-0.3.1.ebuild app-misc/muttprint/muttprint-0.72d-r1.ebuild already done app-shells/fish/fish-1.23.0.ebuild dev-lang/nqc/nqc-2.5.1.ebuild dev-util/valkyrie/valkyrie-1.3.0.ebuild dev-util/valkyrie/valkyrie-1.4.0.ebuild sys-auth/libnss-cache/libnss-cache-0.1.ebuild sys-block/unieject/unieject-5.3.2.ebuild www-apps/swish-e/swish-e-2.4.3-r1.ebuild www-apps/swish-e/swish-e-2.4.3.ebuild Víctor.
Re: [gentoo-dev] make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )
Torsten Veller wrote: * Robin H. Johnson (robbat2) robb...@gentoo.org: 1.1 app-arch/hardlink/hardlink-0.1.1.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/hardlink/hardlink-0.1.1.ebuild?rev=1.1content-type=text/plain src_install() { emake DESTDIR=${D} install ^ || die } 1.1 app-arch/duff/duff-0.4.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/duff/duff-0.4.ebuild?rev=1.1content-type=text/plain src_install() { emake DESTDIR=${D} install ^ || die dodoc AUTHORS ChangeLog HACKING NEWS README* TODO } An imprecise search (/make .*install$/) revealed another 200 packages: http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt Let it die before replacing a working package with a broken one. Thanks sci-chemistry/caver/caver-0.99.2.ebuild sci-chemistry/caver/caver-0.99.4.ebuild Are both outdated and can be removed. (if someone would proxy me for that). I am maintaining a newer version in sci overlay. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Amount of useflags enabled by default
Hi, i would like to start a discussion about reducing the amount of default-enabled USE flags in profiles, especially in inherited basic profiles. Is there any policy, when they are added, how the reason for addition is documented and when they are removed from profiles? In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). Whats the reason for forcing a big load of default enabled USE flags on every user including more dependencies, more compile time, more wasted disk space and more possible vulnerabilities except some users, who complain about a missing feature and are not able to think and enable a USE flag for that feature? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )
On 23/10/09 09:28 +0200, Torsten Veller wrote: An imprecise search (/make .*install$/) revealed another 200 packages: http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt Let it die before replacing a working package with a broken one. Thanks Fixed: sys-cluster/osc-mpiexec/osc-mpiexec-0.83.ebuild sys-cluster/pvfs2/pvfs2-2.7.0-r2.ebuild Thanks. -- Justin Bronder pgpPkLOszttX4.pgp Description: PGP signature
[gentoo-dev] Re: make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Torsten Veller wrote: An imprecise search (/make .*install$/) revealed another 200 packages: http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt Let it die before replacing a working package with a broken one. Removed from tree: kde-base/kdebase/kdebase-3.5.9.ebuild kde-base/kdebase/kdebase-3.5.9-r1.ebuild kde-base/kdebase/kdebase-3.5.9-r2.ebuild kde-base/kdebase/kdebase-3.5.9-r3.ebuild Fixed: kde-base/kdebase/kdebase-3.5.9-r4.ebuild kde-base/kdm/kdm-3.5.10.ebuild - -- Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrh9VoACgkQOypDUo0oQOrTKgCdEPCduNbtJROucNWoc/2m6Nh2 3IgAnjTcTVmWl/4/iwL2umsf+QDiq3Sv =GNW7 -END PGP SIGNATURE-
Re: [gentoo-dev] Amount of useflags enabled by default
Thomas Sachau wrote: In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). I'm not sure for how much of the IUSE=+foo cases this applies but I can explain one of them: In xfce-base/xfce4-session-4.6.1-r1 there is +fortune in IUSE because otherwise previous users of 4.6.1 would be missing the feature enabled by it. If you worry that +foo is becoming a trend _without_ strong reason you could try enforcing documentation for in metadata.xml (through new tags) maybe. Sebastian
Re: [gentoo-dev] Amount of useflags enabled by default
Thomas Sachau wrote: In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). Whats the reason for forcing a big load of default enabled USE flags on every user including more dependencies, more compile time, more wasted disk space and more possible vulnerabilities except some users, who complain about a missing feature and are not able to think and enable a USE flag for that feature? One possible reason is that our packages should follow upstream policy and maybe upstreams usually like to keep things enabled rather than disabled. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eapi files and profiles
Ulrich Mueller wrote: On Fri, 23 Oct 2009, Samuli Suominen wrote: So I was told Council needs to approve inheritance of eapi files from parent profiles? Doesn't http://bugs.gentoo.org/288320#c7 cover this? Why would you need explicit inheritance? Well technically you still shouldn't add EAPI 2 atoms to the child profiles without them being marked with the appropriate eapi file entry. Do all the levels of 10.0 profiles use EAPI 2 entries? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eapi files and profiles
On Fri, 23 Oct 2009 23:26:47 +0300 Petteri Räty betelge...@gentoo.org wrote: Well technically you still shouldn't add EAPI 2 atoms to the child profiles without them being marked with the appropriate eapi file entry. Do all the levels of 10.0 profiles use EAPI 2 entries? Down that way leads madness... Mark any profile directory that itself uses EAPI 1 (there's nothing that makes sense EAPI 2-wise for profiles) as EAPI 1. Leave any other directory alone. Doing it any other way requires far too much careful attention. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] eapi files and profiles
On Fri, 23 Oct 2009 11:24:27 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: So I was told Council needs to approve inheritance of eapi files from parent profiles? As a full explanation of why this idea sucks, since some people have asked: You need to decide which way eapi inherits go. Are you saying that any profile directory with a parent using EAPI X is itself EAPI X? If so, the implications are: * that we can't change the format of the parent file ever (and we have done so in the past) * that it gets a lot harder to remove certain syntax in newer EAPIs. For example, say we want to replace =...* with ranged dependencies in EAPI 4. Then you can't change a profile directory to use EAPI 4 without checking that everything that uses that directory doesn't make use of =...*. Or are you saying that the package manager should use the eapi it picks up for any parents it follows? If so, the implications are: * that removing =...* in EAPI 4 (for example) becomes impossible, because it would be impossible to use that syntax in high level profiles that might be inherited by profiles using EAPI 4. Either way, putting eapi files in any directory that itself specifically needs it is a heck of a lot easier for everyone. On top of that, if you do change it, there's the usual year wait before you can use it, since current package managers don't inherit eapis. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] eapi files and profiles
On Fri, Oct 23, 2009 at 11:24:27AM +0300, Samuli Suominen wrote: So I was told Council needs to approve inheritance of eapi files from parent profiles? I'm not sure why, because we shouldn't have any files in default/linux/ which was decided long ago when the new profiles was introduced... gentoo-x86/profiles/default/linux $ find ./ -name eapi | wc -l 63 That's 63 duplicated files. We should only have one releases/10.0/eapi file, and others wouldn't be required as it would cover all the 10.0 profiles. See, http://bugs.gentoo.org/288320 Can we get a decision on this soon, so we can drop the duplication for 10.1 (or whatever the name for next profile set will be called) ? This is going to break compatibility for pkgcore at least- we limit what forms of atoms are allowed dependant on the eapi of that profile node. I'd hope paludis does the same- I know portage doesn't however. Further... the more I think about this, the more I'm inclined to think this will blow someones foot off. If the eapi is inherited from the parent, what happens when the parent switches to an EAPI that changes the atom parsing rules? Specifically, *restricts* the atom parsing rules? Say that we got rid of the ~ operator w/in EAPI4. '~' is completely valid in the default EAPI=0; if the parent profile switches to EAPI4, it suddenly breaks parsing of any defaulted EAPI that used revision matching. So... inheritance sucks. It gets worse when you have user configuration (custom profiles) inheriting from gentoo-x86 provided profiles- I'd expect user config to use things that are more cutting edge. Alternative approach- the default EAPI currently is 0, and isn't overridable. Add a file into the base of the profile directory that specifies the default EAPI. Via that, you can do your file optimizations- if the majority of profile nodes are eapi=2, then you set the default to 2 and update the nodes that were reliant on the previous default. Note this still requires having this change sit in the tree for a while for compatibilty reasons- but it is a good idea regardless to avoid requiring EAPI to be specified for every single profile node when we've hit EAPI=7 ~harring pgppWjhuwFp66.pgp Description: PGP signature
Re: [gentoo-dev] Amount of useflags enabled by default
Hi, i would like to start a discussion about reducing the amount of default-enabled USE flags in profiles, especially in inherited basic profiles. Sounds like a reasonable idea to me, for the base profiles at least. In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). Whats the reason for forcing a big load of default enabled USE flags on every user including more dependencies, more compile time, more wasted disk space and more possible vulnerabilities except some users, who complain about a missing feature and are not able to think and enable a USE flag for that feature? who complain about a enabled feature and are not able to think and disable a USE flag for that feature? What a couple of changes make It would be nice if we actually documented why they were enabled. Does the use flag enable significant functionality that would otherwise make the software less useful. I believe we should be trying to find a nice 'middle of the road' balance. DE related use flags should be enabled in profiles ( unless of coarse they package is already DE related e.g if a kde package has a use flag for kde's sound system, this could be enabled at a package level while a package with a kde use flag should not default enable it.). So, if we were looking at what use flags ppl are enabling/disabling we should be seeing similar numbers for the +'s and the -'s. Not an easy thing to do, I admit. Would be interesting if something like Color Graphing [1] or some algorithm could be used to determine whether a use flag should be enabled in a profile (including which profile)/package. Maybe we should have some addition metadata for use flags. Like a category/type/blah/blee. As an example we could have a category of DE containing kde/gnome/etc. How do we know that the dirac use flag is codec related without knowing what dirac is? Alistair [1] http://en.wikipedia.org/wiki/Graph_coloring