Re: [gentoo-dev] Allow upstream tags in metadata.xml
On Monday 26 December 2005 16:11, Marcelo Góes wrote: > ``maintainer`` can contain the tags ``name`` and ``email``, indicating the > person/organization responsible for upstream maintainership of the package. What if upstream is more than one person, but less than an organization? What if there is more than one upstream such as for gentoo-sources, where the maintainer of each of the patchsets could be considered an upstream? > ``remote-id`` should specify a type of package identification tracker and > the identification that corresponds to the package in question. > ``remote-id`` should make it easier to index information like its > identification in freshmeat or its cpan identification. if this is to be subject to automated processing, shouldn't there be a registry of valid "type" values maintaining a definition of what the value of the element corresponds to for each type? -- # # electronerd, the electronerdian from electronerdia # pgpq3TIE8wSKi.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On Tuesday 27 December 2005 02:43, Julien Allanos (dju`) wrote: > Are the $HOMEPAGE, $DESCRIPTION possibly > $LICENSE or even $SRC_URI this answer should be pretty obvious, of course these values could change drastically across even revisions, let alone versions > package or version specific then? i'm going to assume you using the word "package" here was a brain fart as all values in an ebuild will be different across packages -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
Le Mardi 27 Décembre 2005 02:52, Dan Meltzer a écrit : > On 12/26/05, Brian Harring <[EMAIL PROTECTED]> wrote: > > On Mon, Dec 26, 2005 at 08:12:03PM -0500, Dan Meltzer wrote: > > > On 12/26/05, Lares Moreau <[EMAIL PROTECTED]> wrote: > > > > On Tue, 2005-12-27 at 00:59 +, Ciaran McCreesh wrote: > > > > > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer > > > > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > | That will increase the sync time for all of our users - can we > > > > > | please keep this info out of the sync-tree? > > > > > > > > > > Learn to use the rsync exclude list. > > > > > > > > I think the point was that the 'average' user needs to pull it as > > > > well and has _no_ use for it. > > > > > > > > There are already complaints about syncs taking to long. > > > > > > The complaints was about the cache, not about the actual sync time > > > > Complaints about both actually- try sync'ing on a crap connection. > > Rsync doesn't scale well the larger the dataset gets (the fact it > > still performs well is a testament to it being mostly a damn fine > > tool). We've got at least a 2.4mB overhead just for doing > > filelist/chksum transfers; that's not getting into pulling the > > _actual_ updates. > > > > > This is what, maybe the equivilent of a new ebuild once, and a -rX any > > > time somethings changed? It won't effect much at all and end up being > > > a lot more helpful (and quickly implemented) than waiting around for > > > someone to write a web database and pushing that through. > > > > Quicker balanced against proper; debate right now is if it's the > > proper place to do this (thus address that concern) :) > > > > > We have metadata.xml's, why not use them? > > > > We have ebuilds, why don't we stick it there? Arguement doesn't work > > well there ;) > > Because its package specific, not version specific :) Are the $HOMEPAGE, $DESCRIPTION, $LICENSE or even $SRC_URI package or version specific then? -- Julien Allanos (dju`) Gentoo Linux Developer (web-apps) GnuPG key: 0x1EC6C6C2 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tuesday 27 December 2005 02:23, Brian Harring wrote:
> On Tue, Dec 27, 2005 at 02:08:25AM -0500, Mike Frysinger wrote:
> > On Tuesday 27 December 2005 02:01, R Hill wrote:
> > > AFAIK most licenses need to be included with the distribution of the
> > > source, not installed on the system after compilation. But I could be
> > > wrong too.
> >
> > anyone who installs a program in portage already has a copy of the
> > license on their system ... $PORTDIR/licenses/
>
> Assuming the tree is locally available (remote, or binpkg's used to
> generate images)...
>
> Lets put it this way; if ebuilds are specifically filtering it out on
> their own, nobody who wants the licenses install has them.
if the user has gone through lengths to cut down on filesize by cutting out
their portage tree, then chances are pretty solid that they are cutting out
things like /usr/share/{doc,man,info} as well which means even if an ebuild
installed the file, it'd be cut anyways from the final filesystem
> If they're installed via the ebuild, and removed via INSTALL_MASK,
> everybody can get what they want. So why nuke by default?
because it's pointless duplication ... the case is either the file is
installed in both places, or not at all ... the people who trim their portage
tree but not /usr/share/doc probably consists of those who do not know how to
trim /usr/share/doc
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tue, Dec 27, 2005 at 02:08:25AM -0500, Mike Frysinger wrote: > On Tuesday 27 December 2005 02:01, R Hill wrote: > > AFAIK most licenses need to be included with the distribution of the > > source, not installed on the system after compilation. But I could be > > wrong too. > > anyone who installs a program in portage already has a copy of the license on > their system ... $PORTDIR/licenses/ Assuming the tree is locally available (remote, or binpkg's used to generate images)... Lets put it this way; if ebuilds are specifically filtering it out on their own, nobody who wants the licenses install has them. If they're installed via the ebuild, and removed via INSTALL_MASK, everybody can get what they want. So why nuke by default? ~harring pgpFZGuIgYNZb.pgp Description: PGP signature
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tuesday 27 December 2005 02:01, R Hill wrote: > AFAIK most licenses need to be included with the distribution of the > source, not installed on the system after compilation. But I could be > wrong too. anyone who installs a program in portage already has a copy of the license on their system ... $PORTDIR/licenses/ -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Installing COPYING or LICENSE files
Carsten Lohrke wrote: > On Monday 26 December 2005 14:57, Drake Wyrm wrote: >> You're going to be hard-pressed to get any kind of consensus on this >> issue. Many dev seems to feel that the license belongs there. In some >> cases the COPYING, LICENSE, and/or INSTALL files contain, not boilerplate >> drivel, but actually unique, useful information. I found that as well, and made sure to only bug people about generic files. In most of those cases COPYING/LICENSE is generic while INSTALL was custom. > Removing these files and relying on LICENSE=foo in the ebuild could be seen > as > a copyright violation. There are lots of samples in /usr/src/licenses that > aren't generic, but include a copyright notice naming the authors of a > particular piece of software, but it doesn't match with all packages under > this license of course. Take ZLIB as example. Since I'm not a lawyer I might > be wrong, but me thinks it would make sense to ask one. AFAIK most licenses need to be included with the distribution of the source, not installed on the system after compilation. But I could be wrong too. --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Tue, Dec 27, 2005 at 12:10:04AM -0500, Chandler Carruth wrote: > Brian Harring wrote: > > >On Mon, Dec 26, 2005 at 11:28:17PM -0500, Chandler Carruth wrote: > >>3) there is _no_ functionality added by any of this, only > >>"user-friendliness" after a fashion, and as such, perhaps it should all > >>be chucked in favor of having users competently declare their own global > >>USE flags during the install, however I doubt that'll get very far. *shrug* You're ignoring the ability to specify additions to the system set; use flags aren't going to help there. > >4) need for the ability to inherit multiple parent profiles. > > > >Otherwise, x86 desktop profile is not guranteed in anyway to reflect > >sparc desktop profile (yes, somewhat the case now). > > > >A gnome desktop profile would make sense imo, but from a work > >standpoint is totally dependant on ability to inherit multiple > >parents. > > > How close is that ability to portage? Is there interest/room for > help/work towards it? 30 minute patch if people want it (line 999 of portage.py from trunk is the area of modification required). Due to current code, would need to either educate users, or come up with some way to make existing code puke when working with N parents- right now the code automatically ignores any other entries in the parent file (ba design choice). > I would like to see a more sensible approach to > establishing default settings (USE flags not the only thing here). IUSE defaults; specifying the use defaults within the ebuild itself (search the -dev archives for it, spanky brought it to the ml iirc). IUSE defaults is not a 30 minute patch. ~harring pgpzBve7MaQJ8.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Brian Harring wrote: >On Mon, Dec 26, 2005 at 11:28:17PM -0500, Chandler Carruth wrote: > > >>It occurs to me that this could be (to an extent) accomplished by having >>a few more "specialized" subprofiles for x86: base, desktop, gnome, and kde. >> >>base - as the name implies, a _basic_ starting point... very similar to >>server profiles, etc. veeery minimal. >>desktop - almost identical to the current USE flags -- what Joe Q. User >>"should" have to be safe, and have programs function as expected. >>gnome / kde - slight specializations of the above to tailor the use >>flags for one desktop environ or the other.. >> >>Problems? >>1) heavier usage and depth of the profile, making where things come in >>more and more obscure. >>2) could lead to proliferation of environment tailored "desktop" >>derivatives. (xfce, fluxbox, the list could go on) This may not be a >>problem as many distros have successfully divided between KDE and Gnome, >>and the base / desktop profiles would allow users ways to customize, as >>always. >>3) there is _no_ functionality added by any of this, only >>"user-friendliness" after a fashion, and as such, perhaps it should all >>be chucked in favor of having users competently declare their own global >>USE flags during the install, however I doubt that'll get very far. *shrug* >> >> > >4) need for the ability to inherit multiple parent profiles. > >Otherwise, x86 desktop profile is not guranteed in anyway to reflect >sparc desktop profile (yes, somewhat the case now). > >A gnome desktop profile would make sense imo, but from a work >standpoint is totally dependant on ability to inherit multiple >parents. > >~harring > > How close is that ability to portage? Is there interest/room for help/work towards it? I would like to see a more sensible approach to establishing default settings (USE flags not the only thing here). Would help the confusion, and end some of the arts/no-arts, eds/no-eds madness. Would also aid end users in beginning to customize their system rather than simply using a default setup. What about the other 3 problems I myself raised? -Chandler Carruth -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Mon, Dec 26, 2005 at 11:28:17PM -0500, Chandler Carruth wrote: > It occurs to me that this could be (to an extent) accomplished by having > a few more "specialized" subprofiles for x86: base, desktop, gnome, and kde. > > base - as the name implies, a _basic_ starting point... very similar to > server profiles, etc. veeery minimal. > desktop - almost identical to the current USE flags -- what Joe Q. User > "should" have to be safe, and have programs function as expected. > gnome / kde - slight specializations of the above to tailor the use > flags for one desktop environ or the other.. > > Problems? > 1) heavier usage and depth of the profile, making where things come in > more and more obscure. > 2) could lead to proliferation of environment tailored "desktop" > derivatives. (xfce, fluxbox, the list could go on) This may not be a > problem as many distros have successfully divided between KDE and Gnome, > and the base / desktop profiles would allow users ways to customize, as > always. > 3) there is _no_ functionality added by any of this, only > "user-friendliness" after a fashion, and as such, perhaps it should all > be chucked in favor of having users competently declare their own global > USE flags during the install, however I doubt that'll get very far. *shrug* 4) need for the ability to inherit multiple parent profiles. Otherwise, x86 desktop profile is not guranteed in anyway to reflect sparc desktop profile (yes, somewhat the case now). A gnome desktop profile would make sense imo, but from a work standpoint is totally dependant on ability to inherit multiple parents. ~harring pgp4ylbEVAr9i.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Lares Moreau wrote: >On Mon, 2005-12-26 at 12:36 -0600, Joe McCann wrote: > > >>For the record, the eds flag was >>added as a default flag because every 3rd gnome user would file bugs or >>complain via forums because they installed gnome, found no >>evolution-data-server integration, and then be bummed when they had to >>recompile packages again. This whole thread seems to have come from a >>misunderstanding of how use.defaults work and 20 min of boredom. >> >> >> > >I'm relatively ignorant of USE Flag intricacies, so please forgive me if >things don't 'fit'. > >Is it feasible and or useful to have a 'meta-flag' that that enables all >the 'necessary' USE flags for a given group of packages? So something >like USE='meta-'. >This has the distinction of being a meta-flag, and as such nothing >really gets turned on 'behind the users back', advanced users can look >into it and see what is being enabled by it and USE='-flag' for the >flags the users doesn't need/want, and expert users would just not use >it. This way meta packages like KDE and Gnome can have their own >meta-flag to do what the need with. > >It also seems to me that more things will need to 'just work' as our >user-base becomes larger and, on average, less advanced. We could amend >the desktop guide to include something like USE='meta-gnome' to the >gnome section. And similar to other meta-flags. > >This may add an unnecessary level of complexity to the use flag system, >but also may be very useful. > > > It occurs to me that this could be (to an extent) accomplished by having a few more "specialized" subprofiles for x86: base, desktop, gnome, and kde. base - as the name implies, a _basic_ starting point... very similar to server profiles, etc. veeery minimal. desktop - almost identical to the current USE flags -- what Joe Q. User "should" have to be safe, and have programs function as expected. gnome / kde - slight specializations of the above to tailor the use flags for one desktop environ or the other.. Problems? 1) heavier usage and depth of the profile, making where things come in more and more obscure. 2) could lead to proliferation of environment tailored "desktop" derivatives. (xfce, fluxbox, the list could go on) This may not be a problem as many distros have successfully divided between KDE and Gnome, and the base / desktop profiles would allow users ways to customize, as always. 3) there is _no_ functionality added by any of this, only "user-friendliness" after a fashion, and as such, perhaps it should all be chucked in favor of having users competently declare their own global USE flags during the install, however I doubt that'll get very far. *shrug* I'm certain there are more/bigger problems with this than I'm seeing, but as an alternative to USE-flag grouping/meta structure/etc, i thought i'd toss out the very flexible profile system we already have available (afaik). =] Profiles are I think underused, but there may well be _good_ reasons for that, so just my 2cents. -Chandler Carruth, yet another gentoo user... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:54:38AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 03:40, Brian Harring wrote: > > The version of digikam being merged requires slot=3.5- it should be > > depending on libk* slot=3.5, also, no? > > No! It (and also its dependencies) can be built against each 3.x slot. > > > As long as the information is represented dependency wise, portage > > should be able to handle it fine. Just need to have that info there. > > It can't be handled dependency wise, because what is interesting is against > which KDE version the relevant ebuilds are actually installed. So note the comment in the email you are responding to about locking down the used dep/rdeps for an install. Via that, could lock down the slot it was compiled against. Bit more to it then that, but the concerns your raising *again* are not use/slot based, your pointing at other portage faults (thus please seperate those concerns from use/slot). ~harring pgpCRl3G2aOe0.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, 27 Dec 2005 03:54:38 +0100 Carsten Lohrke <[EMAIL PROTECTED]> wrote: | On Tuesday 27 December 2005 03:40, Brian Harring wrote: | > The version of digikam being merged requires slot=3.5- it should be | > depending on libk* slot=3.5, also, no? | | No! It (and also its dependencies) can be built against each 3.x slot. But it's not binary compatible between KDE slots. So, once we have :slot dependencies, you should link to a specific :slot (possibly controlled via USE). It's like packages that can use either gtk or gtk2 -- this has to be handled via a USE flag rather than linking against whichever happens to be there. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 03:40, Brian Harring wrote: > The version of digikam being merged requires slot=3.5- it should be > depending on libk* slot=3.5, also, no? No! It (and also its dependencies) can be built against each 3.x slot. > As long as the information is represented dependency wise, portage > should be able to handle it fine. Just need to have that info there. It can't be handled dependency wise, because what is interesting is against which KDE version the relevant ebuilds are actually installed. Carsten pgpcxU0EbgGdg.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:36:00AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 03:11, Brian Harring wrote: > > Never said anything about 2.1 + resolver enhancements (no clue where > > that one came from). Merely commenting on your raised issues about > > use/slot deps. > > From your words. Thanks for destroying my hope in two sentences. ;p > So we add this dependency enhancement without having a Portage version in > place that can resolve issues as they appeare!?! Scary. Who said anything about this going into portage _without_ the resolver enhancements? Re-read my emails, I've stated the resolver improvements are *required* for use/slot to go in (specifically use). So... yeah, you're not following what I've been saying. ~harring pgpc9KHL8TcON.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:32:04AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 03:11, Brian Harring wrote: > > Either way, still not totally following your complaint, thus an actual > > example would help (easiest to assume I'm a moron, and start at that > > level of explanation). > > O.k. > > 1. You have KDE 3.4 and Digikam (version doesn't matter) installed > 2. You update to KDE 3.5 > > What you now have is the following: KDE 3.5 works fine and Digikam as well, > just that it uses KDE 3.4 libs. But what happens: A Digikam update (or you > rebuild for whatever reason). You emerge it (against KDE 3.5), but its > dependencies (libkipi, libkexif ) are still built against kdelibs 3.4. The > result is that compiling Digikam fails. You need to rebuild these > dependencies and every other ebuild depending n those against KDE 3.5. And > Portage should do that transparently. > > For now I have written slot_rebuild() which detects the problem at least and > provides the user with the information what to do, but it's dead ugly. The version of digikam being merged requires slot=3.5- it should be depending on libk* slot=3.5, also, no? As long as the information is represented dependency wise, portage should be able to handle it fine. Just need to have that info there. If an ebuild dep/rdeps via || (), then we're getting into whether or not portage should be filtering || () down to the selected atom... ~harring pgpxKb6IUuH0e.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 03:11, Brian Harring wrote: > Never said anything about 2.1 + resolver enhancements (no clue where > that one came from). Merely commenting on your raised issues about > use/slot deps. From your words. Thanks for destroying my hope in two sentences. ;p So we add this dependency enhancement without having a Portage version in place that can resolve issues as they appeare!?! Scary. Carsten pgpPEvkfU9G2N.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 03:11, Brian Harring wrote: > Either way, still not totally following your complaint, thus an actual > example would help (easiest to assume I'm a moron, and start at that > level of explanation). O.k. 1. You have KDE 3.4 and Digikam (version doesn't matter) installed 2. You update to KDE 3.5 What you now have is the following: KDE 3.5 works fine and Digikam as well, just that it uses KDE 3.4 libs. But what happens: A Digikam update (or you rebuild for whatever reason). You emerge it (against KDE 3.5), but its dependencies (libkipi, libkexif ) are still built against kdelibs 3.4. The result is that compiling Digikam fails. You need to rebuild these dependencies and every other ebuild depending n those against KDE 3.5. And Portage should do that transparently. For now I have written slot_rebuild() which detects the problem at least and provides the user with the information what to do, but it's dead ugly. Carsten pgpndvDJCvSD8.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:07:52AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 02:23, Ciaran McCreesh wrote: > > Nooo! That's exactly the point I was making. Carsten is assuming that > > by using [slot:bar] syntax, no backwards incompatibility will be > > introduced by adding a new [fish:] key. > > Nooo! ;) I said it would look more consistent, than always adding a new way > (§$%&€<> or so) to describe or latest enhanced dependency atom. Either way, it's going to require depset extension, and an EAPI bump. I'd rather deal with it as it comes rather then trying to jam everything into it now. EAPI allows us to do whatever we want once portage aware versions are deployed- I'd rather abuse that then make a mess of use/slot for syntax I personally dislike. :) ~harring pgp2NtLa1e2Zu.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 02:42, Brian Harring wrote: > Well, we all seem to be missing the issue, so please spell it out > clearly (rather then "it's going to get bad"). Didn't grok it from > the previous email, so spell it out please :) Just did so in the answer on your other email. Carsten pgpN7HZsGAEfF.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:01:13AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 02:29, Brian Harring wrote: > > So... basically, your concern is with the resolver, not use/slot deps > > syntax. > > I did not say that this would have anything to do with the syntax. Am I right > to extract from your words that we get rid of ~arch users complains about > up/downgrade cycles with Portage 2.1 as well, but have them confronted with a > proper error message!? :) Never said anything about 2.1 + resolver enhancements (no clue where that one came from). Merely commenting on your raised issues about use/slot deps. > > > - The dependencies we have are always >=kde-libs/kde-x.y and when KDE 4 > > > is due, we can change to =kde-libs/kde-3.5* because everything else won't > > > be supported anymore. So unless I miss something, kde-libs/kde:X is > > > superfluous. > > > > Missing something /me thinks. > > shouldn't really be specifying >=kde-x.y; should be specifying the > > slotting. Do that, and you wouldn't have to go back and change it > > over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a > > different slot. > > Of course slot dependencies are cleaner. Just that they don't address a > practical problem with ebuilds buildable against multiple slotted ebuilds of > one packages, but the need to have them, their dependencies and all other > ebuilds depending on the latter (ones [sp?]) built against one and the same > ebuild ( In reality a set of ebuilds, named KDE X.Y). That sounds more like a failure of the ebuild's dep/rdep specification, either that or your hinting at the need to lock down the rdep's an ebuild was built against. Either way, still not totally following your complaint, thus an actual example would help (easiest to assume I'm a moron, and start at that level of explanation). ~harring pgpQ2ALMkuOU4.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 02:23, Ciaran McCreesh wrote: > Nooo! That's exactly the point I was making. Carsten is assuming that > by using [slot:bar] syntax, no backwards incompatibility will be > introduced by adding a new [fish:] key. Nooo! ;) I said it would look more consistent, than always adding a new way (§$%&€<> or so) to describe or latest enhanced dependency atom. Carsten pgpRoB1lv8bPN.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml
Ciaran McCreesh wrote: On Tue, 27 Dec 2005 02:43:19 +0100 Marius Mauch <[EMAIL PROTECTED]> wrote: | Will those new tags support the "restrict" attribute? Is restrict something that's in use and working, or did it never get off the drawing board? Well, it's listed in metadata.dtd, so any package *could* use it. I currently don't have a tree anywhere near me to check if it is actually used nor do I know if any metadata.xml related tools understand it correctly. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 02:29, Brian Harring wrote: > So... basically, your concern is with the resolver, not use/slot deps > syntax. I did not say that this would have anything to do with the syntax. Am I right to extract from your words that we get rid of ~arch users complains about up/downgrade cycles with Portage 2.1 as well, but have them confronted with a proper error message!? :) > > - The dependencies we have are always >=kde-libs/kde-x.y and when KDE 4 > > is due, we can change to =kde-libs/kde-3.5* because everything else won't > > be supported anymore. So unless I miss something, kde-libs/kde:X is > > superfluous. > > Missing something /me thinks. > shouldn't really be specifying >=kde-x.y; should be specifying the > slotting. Do that, and you wouldn't have to go back and change it > over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a > different slot. Of course slot dependencies are cleaner. Just that they don't address a practical problem with ebuilds buildable against multiple slotted ebuilds of one packages, but the need to have them, their dependencies and all other ebuilds depending on the latter (ones [sp?]) built against one and the same ebuild ( In reality a set of ebuilds, named KDE X.Y). Carsten pgp3UqdzVqgZc.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml
On Tue, 27 Dec 2005 02:43:19 +0100 Marius Mauch <[EMAIL PROTECTED]> wrote: | Will those new tags support the "restrict" attribute? Is restrict something that's in use and working, or did it never get off the drawing board? -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On 12/26/05, Brian Harring <[EMAIL PROTECTED]> wrote: > On Mon, Dec 26, 2005 at 08:12:03PM -0500, Dan Meltzer wrote: > > On 12/26/05, Lares Moreau <[EMAIL PROTECTED]> wrote: > > > On Tue, 2005-12-27 at 00:59 +, Ciaran McCreesh wrote: > > > > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer > > > > <[EMAIL PROTECTED]> wrote: > > > > | That will increase the sync time for all of our users - can we please > > > > | keep this info out of the sync-tree? > > > > > > > > Learn to use the rsync exclude list. > > > > > > > I think the point was that the 'average' user needs to pull it as well > > > and has _no_ use for it. > > > > > > There are already complaints about syncs taking to long. > > > > The complaints was about the cache, not about the actual sync time > > Complaints about both actually- try sync'ing on a crap connection. > Rsync doesn't scale well the larger the dataset gets (the fact it > still performs well is a testament to it being mostly a damn fine > tool). We've got at least a 2.4mB overhead just for doing > filelist/chksum transfers; that's not getting into pulling the > _actual_ updates. > > > > This is what, maybe the equivilent of a new ebuild once, and a -rX any > > time somethings changed? It won't effect much at all and end up being > > a lot more helpful (and quickly implemented) than waiting around for > > someone to write a web database and pushing that through. > > Quicker balanced against proper; debate right now is if it's the > proper place to do this (thus address that concern) :) > > > > We have metadata.xml's, why not use them? > > We have ebuilds, why don't we stick it there? Arguement doesn't work > well there ;) Because its package specific, not version specific :) This is one of the reasons metadata came about in the first place. > > (No I'm not advocating tagging this into ebuilds btw). > ~harring > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Allow upstream tags in metadata.xml
Marcelo Góes wrote: Fellow Gentooers, Here is a draft of an enhancement proposal that should allow upstream information to be included in metadata.xml: http://dev.gentoo.org/~vanquirius/glep-0099.txt It is authored by ciaranm and me (vanquirius). Please comment :-). Will those new tags support the "restrict" attribute? Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 02:31:02AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 01:46, Ciaran McCreesh wrote: > > You solve this either by SLOTting bar and making each bar SLOT use a > > SLOT dep upon KDE, or by using USE flags and [use]:slot deps. > > It's not a that uncommon case and would lead to dozens, very likely > (depending > on the future development of KDE and libs around it) hundreds of duplicated > ebuilds. In short: Your approach would result in a unmaintainable mess and is > not going to become reality. Well, we all seem to be missing the issue, so please spell it out clearly (rather then "it's going to get bad"). Didn't grok it from the previous email, so spell it out please :) ~harring pgpuspkYXF34v.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On Mon, 26 Dec 2005 18:07:29 -0700 Lares Moreau <[EMAIL PROTECTED]> wrote: | On Tue, 2005-12-27 at 00:59 +, Ciaran McCreesh wrote: | > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer | > <[EMAIL PROTECTED]> wrote: | > | That will increase the sync time for all of our users - can we | > | please keep this info out of the sync-tree? | > | > Learn to use the rsync exclude list. | > | I think the point was that the 'average' user needs to pull it as well | and has _no_ use for it. The average user has no need for any of the comments in ebuilds either. Should we remove them? That'll save us 7.5MBytes. Ooh! And indenting! Currently, we're wasting over half a megabyte in ebuilds alone with useless indents. Finally, we can shave off an entire megabyte by removing KDE from the tree. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
Stefan Schweizer wrote: That will increase the sync time for all of our users - can we please keep this info out of the sync-tree? I do not see why this is necessary to be in the tree - we can do fine with a webbased database for that. The additional time is not significant as this will be a gradual change and the added information will rarely change, so the actual effect on sync data is minimal. Having a secondary source of information would be a much bigger problem. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
Lares Moreau wrote: There are already complaints about syncs taking to long. As a dial-up user, I may be one of them. Sorry. It takes me 30 to 45 minutes to sync. That's if it has few changes. It took almost a hour when KDE was upgraded. This does NOT include downloading any packages just the sync. Dale :-) -- To err is human, I'm most certainly human. I have four rigs: 1: Home built; Abit NF7 ver 2.0 w/ AMD 2500+ CPU, 1GB of ram and right now two 80GB hard drives. Named Smoker 2: Home built; Iwill KK266-R w/ AMD 1GHz CPU, 256MBs of ram and a 4GB drive. Named Swifty 3: Home built; Gigabyte GA-71XE4 w/ 800MHz CPU, 224MBs of ram and a 2.5GB drive. Named Pokey 4: Compaq Proliant 6000 Server w/ Quad 200MHz CPUs, 128MBs of ram and a 4.3GB SCSI drive. Named Putput All run Gentoo Linux, all run folding. #1 is my desktop, 2, 3, and 4 are set up as servers. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 01:46, Ciaran McCreesh wrote: > You solve this either by SLOTting bar and making each bar SLOT use a > SLOT dep upon KDE, or by using USE flags and [use]:slot deps. It's not a that uncommon case and would lead to dozens, very likely (depending on the future development of KDE and libs around it) hundreds of duplicated ebuilds. In short: Your approach would result in a unmaintainable mess and is not going to become reality. > The proposed syntax is cleaner than shoving arbitrary stuff inside > [bleh]. You know the disagree thingie. But it's not that I have to ride on it any longer. Carsten pgp46bUeR5vlY.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Lares Moreau wrote: I'm relatively ignorant of USE Flag intricacies, so please forgive me if things don't 'fit'. Ditto for me. I have a question or two. I have servers that have no GUI at all. I just use them to run folding on. Would I benefit from puting in USE="-*" in my USE line? I have been reading this thread and am learning a bit about how this works. It seems that by default Gentoo users do not have as much control as one would think. At least not until you learn how to override the defaults. That may be good for a noobie though. I'm not complaining, just saying that some need the extra hand at first and then as you mature you learn how to override the defaults. I think I just did that by the way. Still to chicken to try it though. :\ I need more "guruness" in me first. LOL Keep up the good work. Oh, answer to the questions would be nice too. :-) Dale :-) -- To err is human, I'm most certainly human. I have four rigs: 1: Home built; Abit NF7 ver 2.0 w/ AMD 2500+ CPU, 1GB of ram and right now two 80GB hard drives. Named Smoker 2: Home built; Iwill KK266-R w/ AMD 1GHz CPU, 256MBs of ram and a 4GB drive. Named Swifty 3: Home built; Gigabyte GA-71XE4 w/ 800MHz CPU, 224MBs of ram and a 2.5GB drive. Named Pokey 4: Compaq Proliant 6000 Server w/ Quad 200MHz CPUs, 128MBs of ram and a 4.3GB SCSI drive. Named Putput All run Gentoo Linux, all run folding. #1 is my desktop, 2, 3, and 4 are set up as servers. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Mon, Dec 26, 2005 at 09:09:31PM +0100, Carsten Lohrke wrote: > On Saturday 24 December 2005 02:04, Brian Harring wrote: > > dev-lang/python[tcltk] > > ^^^ need that atom resolved with use flag tcltk enabled > > I think that's exactly what someone told me months ago. :) > > > >=sys-apps/portage-2.0[sandbox,!build] > > > > ^^^ need >=portage-2.0 merged with sandbox on, build off. > > I wonder if portage deals fine with subtle dependency incompatibilities, when > one package has foo[!bar] and another one foo[bar] as dependency and spits > out a reasonable error message to apply mutual blockers. Actually, you just hit upon one of the main reasons use/slot deps have taken so damn long. Jason can state it better, but our resolver basically chooses a single path when doing the resolution; if that resolution turns out to be an issue during later resolution steps, existing resolver doesn't back track and choose a different (valid) path. Note the up/down cycling bugs. Guess how that comes about? use/slot deps is a combination of depset extension (plus any code that deals with depset), and resolver extension so it handles the extension of depset properly- namely, getting issues from above handled, trying to dig it's way out of use cycles that aren't hard deps, etc. So... basically, your concern is with the resolver, not use/slot deps syntax. > > kde-libs/kde:3 > > ^^^ need any kde, with slotting enabled. > > > > kde-libs/kde:3,4 > > ^^^ need any kde, slotting 3 or 4. > > > > Combination? Not set in stone afaik, the implementation I have > > sitting in saviour doesn't care about the ordering however. > > This is the one I'm entirely not sure what it is good for. To me it looks > more > like a workaround for missing dependency ranges, but it won't solve any issue > for KDE related packages. What are dep ranges? It's the intersection of any version set's specified by common cat/pkgs. In other words, instead of just processing atom by atom, grab the depends, collapse them down into cp->version restrictions, _then_ do the search. The issue you're pointing at isn't use/slot dep based, it's resolver based (again). ;) > - The dependencies we have are always >=kde-libs/kde-x.y and when KDE 4 is > due, we can change to =kde-libs/kde-3.5* because everything else won't be > supported anymore. So unless I miss something, kde-libs/kde:X is superfluous. Missing something /me thinks. shouldn't really be specifying >=kde-x.y; should be specifying the slotting. Do that, and you wouldn't have to go back and change it over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a different slot. Basically... it's how it *should* be done from the get go, rather then going back and fixing things via tweaking the scary eclass y'all have. :) > As a general remark I'd like to know if and how this enhanced dependency > syntax is ordered. :[], []: or is both allowed!? What if we find out, that we > need to consider another factor, later? :[]<>? Like I stated in a previous email, the ordering isn't specified- right now we can split upon [] matches to handle it regardless of ordering, although I'd think some form of ordering would be wise... ~harring pgpQWMlk6YWcl.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On Mon, Dec 26, 2005 at 08:12:03PM -0500, Dan Meltzer wrote: > On 12/26/05, Lares Moreau <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-12-27 at 00:59 +, Ciaran McCreesh wrote: > > > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer > > > <[EMAIL PROTECTED]> wrote: > > > | That will increase the sync time for all of our users - can we please > > > | keep this info out of the sync-tree? > > > > > > Learn to use the rsync exclude list. > > > > > I think the point was that the 'average' user needs to pull it as well > > and has _no_ use for it. > > > > There are already complaints about syncs taking to long. > > The complaints was about the cache, not about the actual sync time Complaints about both actually- try sync'ing on a crap connection. Rsync doesn't scale well the larger the dataset gets (the fact it still performs well is a testament to it being mostly a damn fine tool). We've got at least a 2.4mB overhead just for doing filelist/chksum transfers; that's not getting into pulling the _actual_ updates. > This is what, maybe the equivilent of a new ebuild once, and a -rX any > time somethings changed? It won't effect much at all and end up being > a lot more helpful (and quickly implemented) than waiting around for > someone to write a web database and pushing that through. Quicker balanced against proper; debate right now is if it's the proper place to do this (thus address that concern) :) > We have metadata.xml's, why not use them? We have ebuilds, why don't we stick it there? Arguement doesn't work well there ;) (No I'm not advocating tagging this into ebuilds btw). ~harring pgph86K44E7lU.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Mon, 26 Dec 2005 17:17:54 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: | On Tue, Dec 27, 2005 at 01:03:49AM +, Ciaran McCreesh wrote: | > On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring | > <[EMAIL PROTECTED]> wrote: | > | Not saying it's a great idea, but EAPI exists to provide | > | immediate transition to incompatible changes instead of the usual | > | "work out a semi backwards compatible way, don't use it for 6 | > | months, then deal with the bugs". | > | > Addition of any new dependency filtering criterion is a backwards | > incompatible change anyway. If you add, say, [fish:trout] and older | > versions of Portage don't recognise [fish:], there's no way for said | > older Portage versions to know what to do. Being able to parse | > additional DEPEND constructs is not sufficient. | | Guessing you're missing how EAPI works. The scenario you're pointing | at isn't an issue for EAPI aware portage versions. Nooo! That's exactly the point I was making. Carsten is assuming that by using [slot:bar] syntax, no backwards incompatibility will be introduced by adding a new [fish:] key. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 01:03:49AM +, Ciaran McCreesh wrote: > On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | Not saying it's a great idea, but EAPI exists to provide immediate > | transition to incompatible changes instead of the usual "work out a > | semi backwards compatible way, don't use it for 6 months, then deal > | with the bugs". > > Addition of any new dependency filtering criterion is a backwards > incompatible change anyway. If you add, say, [fish:trout] and older > versions of Portage don't recognise [fish:], there's no way for said > older Portage versions to know what to do. Being able to parse > additional DEPEND constructs is not sufficient. Guessing you're missing how EAPI works. The scenario you're pointing at isn't an issue for EAPI aware portage versions. If portage doesn't know of that EAPI version, it flat out won't do _any_ operations on that package; it's filtered out of available packages. Hell, we don't even store the metadata in the cache- the reasoning being that if we don't know of that EAPI version, there is _no_ gurantee we'll even be processing the metadata dumped from ebuild.sh properly (nor that ebuild.sh will produce proper metadata for that eapi). So... for scenario above, portage sees the differing EAPI, masks the package on it's own- the new dependency format isn't seen, nor processed by portage. Like I said, via EAPI we can effectively break whatever we want format wise, do a total quick cut over without breaking older eapi aware portages (this is the reason eapi exists). Non eapi aware portage's will be boned, but so it goes. They're going to be progressively more screwed the further we go portage wise anyways, so it's something of a lost cause (imo). ~harring pgp73LMMl2yGl.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On 12/26/05, Lares Moreau <[EMAIL PROTECTED]> wrote: > On Tue, 2005-12-27 at 00:59 +, Ciaran McCreesh wrote: > > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer > > <[EMAIL PROTECTED]> wrote: > > | That will increase the sync time for all of our users - can we please > > | keep this info out of the sync-tree? > > > > Learn to use the rsync exclude list. > > > I think the point was that the 'average' user needs to pull it as well > and has _no_ use for it. > > There are already complaints about syncs taking to long. The complaints was about the cache, not about the actual sync time This is what, maybe the equivilent of a new ebuild once, and a -rX any time somethings changed? It won't effect much at all and end up being a lot more helpful (and quickly implemented) than waiting around for someone to write a web database and pushing that through. We have metadata.xml's, why not use them? > > -- > Lares Moreau <[EMAIL PROTECTED]> | LRU: 400755 http://counter.li.org > lares/irc.freenode.net | > Gentoo x86 Arch Tester | ::0 Alberta, Canada > Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred > Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBDsJPRfZRIPg1Gu24RAuwnAJ4uLZw5Vu2dHM1pe2xSdiGwvPXH7wCg2yCt > Hpb7QrVs/RJ5Tiz4iyI0ipM= > =k3qI > -END PGP SIGNATURE- > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On Tue, Dec 27, 2005 at 12:59:34AM +, Ciaran McCreesh wrote: > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer > <[EMAIL PROTECTED]> wrote: > | That will increase the sync time for all of our users - can we please > | keep this info out of the sync-tree? > > Learn to use the rsync exclude list. metadata.xml is/will be required someday due to long description being stuck in there. Excluding it isn't incredibly useful in light of that. Personally... would rather see maintainer info stuck somewhere else, but not something I'm going to fight tooth and nail over. ~harring pgpopukAAH02V.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On Tue, 2005-12-27 at 00:59 +, Ciaran McCreesh wrote: > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer > <[EMAIL PROTECTED]> wrote: > | That will increase the sync time for all of our users - can we please > | keep this info out of the sync-tree? > > Learn to use the rsync exclude list. > I think the point was that the 'average' user needs to pull it as well and has _no_ use for it. There are already complaints about syncs taking to long. -- Lares Moreau <[EMAIL PROTECTED]> | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Multiple Repo Support
On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: | Not saying it's a great idea, but EAPI exists to provide immediate | transition to incompatible changes instead of the usual "work out a | semi backwards compatible way, don't use it for 6 months, then deal | with the bugs". Addition of any new dependency filtering criterion is a backwards incompatible change anyway. If you add, say, [fish:trout] and older versions of Portage don't recognise [fish:], there's no way for said older Portage versions to know what to do. Being able to parse additional DEPEND constructs is not sufficient. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer <[EMAIL PROTECTED]> wrote: | That will increase the sync time for all of our users - can we please | keep this info out of the sync-tree? Learn to use the rsync exclude list. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 12:46:49AM +, Ciaran McCreesh wrote: > | > The existing syntax is just as extensible. Up the EABI revision, and > | > start adding new syntax as needed. > | > | EAPI has nothing to do with the consistency of the syntax. Getting it > | once right, is what you usually call for. I prefer clean data > | structures. > > The proposed syntax is cleaner than shoving arbitrary stuff inside > [bleh]. Any new [role:] tags will require an EABI bump anyway, so > there's no reason to stick to your proposed syntax to avoid future > backwards compatibility breaks. Expanding a bit... Via eapi, if we wanted to throw out the syntax down the line we could. Not saying it's a great idea, but EAPI exists to provide immediate transition to incompatible changes instead of the usual "work out a semi backwards compatible way, don't use it for 6 months, then deal with the bugs". ~harring pgp1G7nGB2yqm.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, 27 Dec 2005 01:33:13 +0100 Carsten Lohrke <[EMAIL PROTECTED]> wrote: | The problem is not the SLOT change, but to build "foo" depending on | "bar" against KDE X, while bar is built against KDE Y. "foo" and | "bar" support all slotted KDE versions, but they need to be build | against the same one. You simply cannot express this via slot | dependencies, so this feature is useless for KDE packages. You solve this either by SLOTting bar and making each bar SLOT use a SLOT dep upon KDE, or by using USE flags and [use]:slot deps. | > The existing syntax is just as extensible. Up the EABI revision, and | > start adding new syntax as needed. | | EAPI has nothing to do with the consistency of the syntax. Getting it | once right, is what you usually call for. I prefer clean data | structures. The proposed syntax is cleaner than shoving arbitrary stuff inside [bleh]. Any new [role:] tags will require an EABI bump anyway, so there's no reason to stick to your proposed syntax to avoid future backwards compatibility breaks. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
That will increase the sync time for all of our users - can we please keep this info out of the sync-tree? I do not see why this is necessary to be in the tree - we can do fine with a webbased database for that. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Monday 26 December 2005 21:28, Ciaran McCreesh wrote: > If they're purely in DEPEND, that one isn't even an incompatability. Right. But it's not that unlikely to see such a corner case sooner or later and it would be good if Portage catches it, instead spitting out a weird message, leaving the root of the issue in the dark. Should be also simple to write a test case. > Well, any library that changes ABI should use a different SLOT for each > revision. So SLOT depends should be able to replace the need for = and > ~ and < and <= dependencies entirely. Which is a good thing, since > those atoms make dependency resolution a general-case unsolvable > problem. The problem is not the SLOT change, but to build "foo" depending on "bar" against KDE X, while bar is built against KDE Y. "foo" and "bar" support all slotted KDE versions, but they need to be build against the same one. You simply cannot express this via slot dependencies, so this feature is useless for KDE packages. > The existing syntax is just as extensible. Up the EABI revision, and > start adding new syntax as needed. EAPI has nothing to do with the consistency of the syntax. Getting it once right, is what you usually call for. I prefer clean data structures. Carsten pgpuUpWXh9dlB.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On Mon, 26 Dec 2005 22:11:46 -0200 Marcelo Góes <[EMAIL PROTECTED]> wrote: | Here is a draft of an enhancement proposal that should allow upstream | information to be included in metadata.xml: | | http://dev.gentoo.org/~vanquirius/glep-0099.txt Should show up in nicely rendered HTML here within an hour or three: http://www.gentoo.org/proj/en/glep/glep-0046.html Unless I screwed up, of course. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Allow upstream tags in metadata.xml
Fellow Gentooers, Here is a draft of an enhancement proposal that should allow upstream information to be included in metadata.xml: http://dev.gentoo.org/~vanquirius/glep-0099.txt It is authored by ciaranm and me (vanquirius). Please comment :-). Cheers, Marcelo -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Lares Moreau wrote: On Mon, 2005-12-26 at 12:36 -0600, Joe McCann wrote: For the record, the eds flag was added as a default flag because every 3rd gnome user would file bugs or complain via forums because they installed gnome, found no evolution-data-server integration, and then be bummed when they had to recompile packages again. This whole thread seems to have come from a misunderstanding of how use.defaults work and 20 min of boredom. I'm relatively ignorant of USE Flag intricacies, so please forgive me if things don't 'fit'. Is it feasible and or useful to have a 'meta-flag' that that enables all the 'necessary' USE flags for a given group of packages? So something like USE='meta-'. This has the distinction of being a meta-flag, and as such nothing really gets turned on 'behind the users back', advanced users can look into it and see what is being enabled by it and USE='-flag' for the flags the users doesn't need/want, and expert users would just not use it. This way meta packages like KDE and Gnome can have their own meta-flag to do what the need with. It also seems to me that more things will need to 'just work' as our user-base becomes larger and, on average, less advanced. We could amend the desktop guide to include something like USE='meta-gnome' to the gnome section. And similar to other meta-flags. This may add an unnecessary level of complexity to the use flag system, but also may be very useful. If I remember right theres a GLEP (#29) that purposes to do something very similar (USE Groups I think it was called), but I believe its withdrawn. Regards, Andrew Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Mon, 26 Dec 2005 15:19:47 -0700 Lares Moreau <[EMAIL PROTECTED]> wrote: | Is it feasible and or useful to have a 'meta-flag' that that enables | all the 'necessary' USE flags for a given group of packages? So | something like USE='meta-'. USE flags are for things that're optional, not things that are necessary, so your request doesn't make sense. If you mean "to avoid that icky built_with_use error", we're getting foo[bar] deps soon anyway, so it's better to avoid polluting the tree with even more nastiness. Your other option... would be to revive GLEP 29. Be warned, however, that in the form in which I left it, GLEP 29 doesn't solve many of the problems that developers would expect a "USE flag grouping" GLEP to solve. In particular, it doesn't provide anything that would help with USE flag editing tools. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning
On Mon, 2005-12-26 at 12:36 -0600, Joe McCann wrote: > > For the record, the eds flag was > added as a default flag because every 3rd gnome user would file bugs or > complain via forums because they installed gnome, found no > evolution-data-server integration, and then be bummed when they had to > recompile packages again. This whole thread seems to have come from a > misunderstanding of how use.defaults work and 20 min of boredom. > I'm relatively ignorant of USE Flag intricacies, so please forgive me if things don't 'fit'. Is it feasible and or useful to have a 'meta-flag' that that enables all the 'necessary' USE flags for a given group of packages? So something like USE='meta-'. This has the distinction of being a meta-flag, and as such nothing really gets turned on 'behind the users back', advanced users can look into it and see what is being enabled by it and USE='-flag' for the flags the users doesn't need/want, and expert users would just not use it. This way meta packages like KDE and Gnome can have their own meta-flag to do what the need with. It also seems to me that more things will need to 'just work' as our user-base becomes larger and, on average, less advanced. We could amend the desktop guide to include something like USE='meta-gnome' to the gnome section. And similar to other meta-flags. This may add an unnecessary level of complexity to the use flag system, but also may be very useful. -- Lares Moreau <[EMAIL PROTECTED]> | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Binary packages in the tree
Mark Loeser <[EMAIL PROTECTED]> said: > Mark Loeser <[EMAIL PROTECTED]> said: > > So, everyone that has a binary package in the tree, I would appreciate it if > > you could put the sys-libs/libstdc++-v3 depend into your package if > > necessary. > > Well, you can tell I didn't exactly think about this too much beforehand, > since its been brought to my attention a virtual would probably be best for > this, so we would handle the || ( gcc-3.3.* libstdc++ ) inside of the > virtual. I'll make one later unless anyone has strong objections to this for > people to use in DEPEND, instead of writing the `or` dep out. Okay, I have added the new-style virtual. If you have a binary application in the tree that requires libstdc++.so.5, please add a dep in your ebuild on =virtual/libstdc++-3.3. Let me know if anything doesn't seem to work right. Thanks -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpSuw2xr1Dz3.pgp Description: PGP signature
Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning
26.12.2005, 22:21:14, Diego 'Flameeyes' Petteno wrote: > On Monday 26 December 2005 20:24, Jakub Moc wrote: >> exactly the same thing with motif - would >> someone explain why the heck do do we need this thing in make.defaults? > Because people emerges xpdf waiting for xpdf binary and they won't find it > with -motif, as it requires motif integration Eeek?! This is totally broken behaviour... > , but I think more people would > just have xpdf installed because of cups or older kpdf/gpdf versions. > Now that poppler is there, the problem might be mitigated, in the future, tho, > as cups still uses xpdf and not poppler yet. That would be really nice... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpXbJO9BVhi7.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Monday 26 December 2005 20:24, Jakub Moc wrote: > exactly the same thing with motif - would > someone explain why the heck do do we need this thing in make.defaults? Because people emerges xpdf waiting for xpdf binary and they won't find it with -motif, as it requires motif integration, but I think more people would just have xpdf installed because of cups or older kpdf/gpdf versions. Now that poppler is there, the problem might be mitigated, in the future, tho, as cups still uses xpdf and not poppler yet. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpZOJe0D9UT8.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
OK, so because every 3rd gnome user is not able to add the proper use flag to make.conf, every non-gnome user is stuck with investigating and putting -eds into make.conf to avoid pulling in gnome crap. Wonderful. Yes, I am ranting, because this kind of use flags basically pulls in huge number or unwanted dependencies; exactly the same thing with motif - would someone explain why the heck do do we need this thing in make.defaults? I can say the same thing for people who are to lazy to add the proper -use flag(when it is much more obvious that deps you don't want are being pulled in compared to support you do want not being compiled in). Unless this is going to go beyond ranting, there isn't much point from either side. In this case, you are wrong. These USE flags are not doing what they are intended to do because of eds. If a user explicitly sets -gtk -gnome, and gnome *still* is pulled in because of eds in the default profile, this is broken behavior. I also suspect that "every 3rd gnome user" is a minority compared to the number of folks who are affected by forcing eds. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: $BUILDDIR in ebuilds
On Monday 26 December 2005 08:24, Drake Wyrm wrote:
> Brian Harring <[EMAIL PROTECTED]> wrote:
> > On Mon, Dec 26, 2005 at 02:51:26AM -0500, Michael Sterrett -Mr. Bones.-
wrote:
> > > Like in here?
> > >
> > > app-doc/halibut/halibut-0.9.ebuild: BUILDDIR="${S}/build" \
> > > net-dns/maradns/maradns-1.0.27.ebuild:
> > > BUILDDIR=${S}/build \ net-dns/maradns/maradns-1.0.32.ebuild:
> > > BUILDDIR=${S}/build \
>
> [snip]
>
> > Either way, those 3 are fine- they're not relying on portage provided
> > BUILDDIR var, just issueing a directive to make.
>
> In that case, shouldn't they use something like BUILDDIR="$BUILDDIR" to
> supply the argument to make?
that is how they're being used :P
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Installing COPYING or LICENSE files
On Monday 26 December 2005 08:24, Petteri Räty wrote: > Petteri Räty wrote: > > R Hill wrote: > >>Daniel Ahlberg wrote: > >>>* if ebuild installs COPYING and/or INSTALL into doc. > >> > >>Is this actually important? There are a hell of a lot of ebuilds that > >> fail under this rule. I'd like to start filing patches for some of the > >> packages in this list so I'm interested in knowing what's worth fixing > >> and what's being pedantic. > > > > Not a blocker but just useless. Filing patches for ebuilds doing this is > > greatly appreciated by at least me. > > So is there a policy about [not] installing the COPYING or LICENSE files > already? If there isn't one, I propose we make a decision about this to > have uniform behaviour across the tree. there isnt one but i'm all for not installing COPYING/LICENSE/ABOUT-NLS files i dont mind the INSTALL/etc... files because often they contain information that is useful for things other than just configure/make -mike -- gentoo-dev@gentoo.org mailing list
Re: Re[4]: [gentoo-dev] Stupid USE defaults that need cleaning
On Mon, 2005-12-26 at 20:24 +0100, Jakub Moc wrote: > 26.12.2005, 19:36:23, Joe McCann wrote: > > > On Mon, 2005-12-26 at 17:57 +0100, Jakub Moc wrote: > > >> eds - please, fix the ebuilds properly instead of throwing the thing on > >> everyone. This has already caused numerous invalid bugs with people > >> wondering why the heck portage wants to emerge gnome with USE="-gtk -gnome" > >> > > > For the record, the eds flag was added as a default flag because every 3rd > > gnome user would file bugs or complain via forums because they installed > > gnome, found no evolution-data-server integration, and then be bummed when > > they had to recompile packages again. This whole thread seems to have come > > from a misunderstanding of how use.defaults work and 20 min of boredom. > > OK, so because every 3rd gnome user is not able to add the proper use flag > to make.conf, every non-gnome user is stuck with investigating and putting > -eds into make.conf to avoid pulling in gnome crap. Wonderful. > > Yes, I am ranting, because this kind of use flags basically pulls in huge > number or unwanted dependencies; exactly the same thing with motif - would > someone explain why the heck do do we need this thing in make.defaults? > I can say the same thing for people who are to lazy to add the proper -use flag(when it is much more obvious that deps you don't want are being pulled in compared to support you do want not being compiled in). Unless this is going to go beyond ranting, there isn't much point from either side. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke <[EMAIL PROTECTED]> wrote: | I wonder if portage deals fine with subtle dependency | incompatibilities, when one package has foo[!bar] and another one | foo[bar] as dependency and spits out a reasonable error message to | apply mutual blockers. If they're purely in DEPEND, that one isn't even an incompatability. | > kde-libs/kde:3 | > ^^^ need any kde, with slotting enabled. | > | > kde-libs/kde:3,4 | > ^^^ need any kde, slotting 3 or 4. | > | > Combination? Not set in stone afaik, the implementation I have | > sitting in saviour doesn't care about the ordering however. | | This is the one I'm entirely not sure what it is good for. To me it | looks more like a workaround for missing dependency ranges, but it | won't solve any issue for KDE related packages. Well, any library that changes ABI should use a different SLOT for each revision. So SLOT depends should be able to replace the need for = and ~ and < and <= dependencies entirely. Which is a good thing, since those atoms make dependency resolution a general-case unsolvable problem. | As a general remark I'd like to know if and how this enhanced | dependency syntax is ordered. :[], []: or is both allowed!? What if | we find out, that we need to consider another factor, later? :[]<>? | Wouldn't it be better to have a extensible scheme, like e.g. | $category/$ebuild[use:foo,!bar;slot:x,y] ? The existing syntax is just as extensible. Up the EABI revision, and start adding new syntax as needed. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 02:04, Brian Harring wrote: > dev-lang/python[tcltk] > ^^^ need that atom resolved with use flag tcltk enabled I think that's exactly what someone told me months ago. :) > >=sys-apps/portage-2.0[sandbox,!build] > > ^^^ need >=portage-2.0 merged with sandbox on, build off. I wonder if portage deals fine with subtle dependency incompatibilities, when one package has foo[!bar] and another one foo[bar] as dependency and spits out a reasonable error message to apply mutual blockers. > kde-libs/kde:3 > ^^^ need any kde, with slotting enabled. > > kde-libs/kde:3,4 > ^^^ need any kde, slotting 3 or 4. > > Combination? Not set in stone afaik, the implementation I have > sitting in saviour doesn't care about the ordering however. This is the one I'm entirely not sure what it is good for. To me it looks more like a workaround for missing dependency ranges, but it won't solve any issue for KDE related packages. - The dependencies we have are always >=kde-libs/kde-x.y and when KDE 4 is due, we can change to =kde-libs/kde-3.5* because everything else won't be supported anymore. So unless I miss something, kde-libs/kde:X is superfluous. - What we need is that ebuilds build against KDE slot X force a rebuild of those dependencies, which were against KDE slot Y as well as every other installed ebuild depending on them. Right now my fugly slot_rebuild() workaround lets the user do the job by hand. As a general remark I'd like to know if and how this enhanced dependency syntax is ordered. :[], []: or is both allowed!? What if we find out, that we need to consider another factor, later? :[]<>? Wouldn't it be better to have a extensible scheme, like e.g. $category/$ebuild[use:foo,!bar;slot:x,y] ? Carsten pgpu4QYUzO1bD.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Mon, 26 Dec 2005 20:03:42 +0100 Carsten Lohrke <[EMAIL PROTECTED]> wrote: | On Monday 26 December 2005 18:07, Ciaran McCreesh wrote: | > Because it makes sense. For any application which has IUSE="emboss", | > chances are emboss should be enabled. There was a long discussion | > about this on the -user list a while back where I ended up posting a | > newbie-friendly explanation of the whole thing. Perhaps you could | > hunt it down on marc or gmane and post a link here... | | Probably you should have provided the link, because the question that | comes to mind is, why this dependency is optional at all, when it | should be enabled anyways!? Because there are legitimate reasons for turning it off. They're just significantly less likely to occur than the reasons for wanting it turned on. And of course, if you don't use any apps that have IUSE="emboss", the default value of the USE flag is entirely irrelevant to you. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re[4]: [gentoo-dev] Stupid USE defaults that need cleaning
26.12.2005, 19:36:23, Joe McCann wrote: > On Mon, 2005-12-26 at 17:57 +0100, Jakub Moc wrote: >> eds - please, fix the ebuilds properly instead of throwing the thing on >> everyone. This has already caused numerous invalid bugs with people >> wondering why the heck portage wants to emerge gnome with USE="-gtk -gnome" >> > For the record, the eds flag was added as a default flag because every 3rd > gnome user would file bugs or complain via forums because they installed > gnome, found no evolution-data-server integration, and then be bummed when > they had to recompile packages again. This whole thread seems to have come > from a misunderstanding of how use.defaults work and 20 min of boredom. OK, so because every 3rd gnome user is not able to add the proper use flag to make.conf, every non-gnome user is stuck with investigating and putting -eds into make.conf to avoid pulling in gnome crap. Wonderful. Yes, I am ranting, because this kind of use flags basically pulls in huge number or unwanted dependencies; exactly the same thing with motif - would someone explain why the heck do do we need this thing in make.defaults? I don't think that this discussion will lead somewhere, so - anyone cares to add a non-bloated x86 profile (basically, something like profiles/hardened/x86/2.6 minus the hardened stuff) so that people who don't want all this bloat can have a sane starting point? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp7yuTYcnogo.pgp Description: PGP signature
[gentoo-dev] Re: Stupid USE defaults that need cleaning
Jakub Moc posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 26 Dec 2005 18:53:55 +0100: > > 26.12.2005, 18:07:45, Ciaran McCreesh wrote: > >> On Mon, 26 Dec 2005 17:57:17 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: >> | alsa - this does not make most sense definitely, this horrible thing >> | needs to die. > >> Why? On x86, alsa is the least broken sound system, and on x86, the >> target for the default profiles is desktops, and most desktops have >> soundcards. > > Uh eh... I meant *arts*, no clue how I wrote alsa. USE=arts is a great default, again, by the definition already given "for packages that can optionally support arts, should it be enabled by default or not". Most of the arts-optional packages will be KDE. KDE by default should be arts-aware, at least in KDE 3.x. 4.x will be a different matter, but with 3.x, while KDE /can/ run without arts, it's /designed/ to run /with/ arts, so that's the entirely logical default. Of course, there are packages such as xmms that don't have an direct relationship to KDE save that they optionally support arts. Great! For such packages there's this user-configurable file in /etc/portage called package.use. For those that don't want arts at all, simply set -arts in make.conf and be done with it. Meanwhile, USE=arts remains an entirely logical default. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Monday 26 December 2005 18:07, Ciaran McCreesh wrote: > Because it makes sense. For any application which has IUSE="emboss", > chances are emboss should be enabled. There was a long discussion about > this on the -user list a while back where I ended up posting a > newbie-friendly explanation of the whole thing. Perhaps you could hunt > it down on marc or gmane and post a link here... Probably you should have provided the link, because the question that comes to mind is, why this dependency is optional at all, when it should be enabled anyways!? Carsten pgpgudF0puG3p.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Monday 26 December 2005 19:36, Joe McCann wrote: > This whole thread seems to have come from a > misunderstanding of how use.defaults work and 20 min of boredom. use.defaults are based on the idea that having an ebuild installed should activate the relevant use flag(s) behind the users back. This idea is plain wrong, but has nothing to do with Doug's Christmas day rant. Carsten pgpmSsEbPHRWx.pgp Description: PGP signature
Re: Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning
On Mon, 2005-12-26 at 17:57 +0100, Jakub Moc wrote: > eds - please, fix the ebuilds properly instead of throwing the thing on > everyone. This has already caused numerous invalid bugs with people > wondering why the heck portage wants to emerge gnome with USE="-gtk -gnome" > How do you suggest the ebuilds be fixed properly? per ebuild use defaults that don't exist? This is the 2nd time somebody has mentioned fixing the ebuilds, without really backing it up with anything. Unless y'all have something in mind, please stop using phrases like "fix your ebuilds" to make it look like you have a point. I'm sorry for the time you have spent with invalid bugs(and you are doing a good job since I've never seen one..kudos), I know that is a drag and doesn't really help anybody in the long run, but this argument is no different then the argument for any other default flag. For the record, the eds flag was added as a default flag because every 3rd gnome user would file bugs or complain via forums because they installed gnome, found no evolution-data-server integration, and then be bummed when they had to recompile packages again. This whole thread seems to have come from a misunderstanding of how use.defaults work and 20 min of boredom. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Simon Stelling wrote: > Doug Goldstein wrote: > >> the USE defaults are a bit INSANE... We need to get rid of some of this >> crap... >> >> >> ./default-linux/x86/2005.0/make.defaults:USE="alsa apm arts avi berkdb >> bitmap-fo nts crypt cups eds emboss encode fortran foomaticdb gdbm gif >> gnome gpm gstreamer gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad >> mikmod motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib >> perl png python qt quicktime readline sdl spell ssl tcpd truetype >> truetype-fonts type1-fonts vorbis X xml2 xmms xv zlib" > > > What about discussing this with the x86 arch team instead of -dev? IMO > it's pretty much their decision what their defaults look like. > Because looking at the CVS logs to who is commiting these changes to the profile and then looking at the x86 ARCH team I can tell you that a lot of the USE flags I disagree with weren't put there by the ARCH teams. And sometimes developers just add stuff there without properly discussing things, there's a few USE flags like that. So really the proper forums was here so that all devs were aware. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Petteri Räty wrote: Bastiaan Visser wrote: On Monday 26 December 2005 09:33, Mike Frysinger wrote: On Monday 26 December 2005 02:24, Doug Goldstein wrote: well there is always USE enabling... (i.e. When I emerge x11-libs/qt, it'll turn on the "qt" USE flag) which we've already established quite clearly as something we wish to get rid of completely -mike aint it worth it to mention "-*" in the handbook ? And then mentioning stuff like pam that almost everyone wants? There are also things that should be on by default. Regards, Petteri Actually, Pam is a pain for me and i always turn it off. But thats just my $.02, alot of the very specific use flags shouldn't be turned on by default. Which ones need to be removed is up to _a_lot_ of discussion. -Tux -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning
26.12.2005, 18:07:45, Ciaran McCreesh wrote: > On Mon, 26 Dec 2005 17:57:17 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > | alsa - this does not make most sense definitely, this horrible thing > | needs to die. > Why? On x86, alsa is the least broken sound system, and on x86, the > target for the default profiles is desktops, and most desktops have > soundcards. Uh eh... I meant *arts*, no clue how I wrote alsa. -- jakub pgp54Gtoj1uG5.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Doug Goldstein wrote: the USE defaults are a bit INSANE... We need to get rid of some of this crap... ./default-linux/x86/2005.0/make.defaults:USE="alsa apm arts avi berkdb bitmap-fo nts crypt cups eds emboss encode fortran foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl tcpd truetype truetype-fonts type1-fonts vorbis X xml2 xmms xv zlib" What about discussing this with the x86 arch team instead of -dev? IMO it's pretty much their decision what their defaults look like. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Mon, 26 Dec 2005 17:57:17 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: | alsa - this does not make most sense definitely, this horrible thing | needs to die. Why? On x86, alsa is the least broken sound system, and on x86, the target for the default profiles is desktops, and most desktops have soundcards. | emboss - "Adds support for the European Molecular Biology Open | Software Suite." WTF? Why are we abusing make.defaults for such stuff? Because it makes sense. For any application which has IUSE="emboss", chances are emboss should be enabled. There was a long discussion about this on the -user list a while back where I ended up posting a newbie-friendly explanation of the whole thing. Perhaps you could hunt it down on marc or gmane and post a link here... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning
26.12.2005, 16:35:33, Ciaran McCreesh wrote: > On Mon, 26 Dec 2005 00:09:57 -0500 Doug Goldstein <[EMAIL PROTECTED]> > wrote: > | the USE defaults are a bit INSANE... We need to get rid of some of > | this crap... > No, you just don't understand how they work. It's not an issue of > "is foo important". It's an issue of "for packages with optional foo > support, does it make most sense for foo to be enabled by default?". OK, then: alsa - this does not make most sense definitely, this horrible thing needs to die. emboss - "Adds support for the European Molecular Biology Open Software Suite." WTF? Why are we abusing make.defaults for such stuff? eds - please, fix the ebuilds properly instead of throwing the thing on everyone. This has already caused numerous invalid bugs with people wondering why the heck portage wants to emerge gnome with USE="-gtk -gnome" motif - no need to repeat Cardoe's description... and this has caused tons of "cups depends on X" bugs. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp2215uzTW7p.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Monday 26 December 2005 17:32, Jan Kundrát wrote: > If it should be on by default, let's add it to the profile, don't ask > users to turn it on themselves. That s what it s done now. But -* would disable it... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpbt2L1P6CIf.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Petteri Räty wrote: >>aint it worth it to mention "-*" in the handbook ? If you make a decision, http://bugs.gentoo.org/ please. > And then mentioning stuff like pam that almost everyone wants? There are > also things that should be on by default. If it should be on by default, let's add it to the profile, don't ask users to turn it on themselves. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Dale wrote: > I'm not a dev but I can see both sides. I learned why some things are > being pulled in that I couldn't figure out. I use KDE but do not want > Gnome and it appears that I have some gnome stuff installed and didn't > know it, because of the USE line. I guess they are in there because of > people that are still noobies and don't know any better, like me maybe. > > Maybe there needs to be more info about what is in the defaults so > people will know. I see now that I need to put -gnome in mine. I have > a lot of gnome stuff installed and had no clue I needed -gnome until I > read this. Why don't you read the documentation [1] then? [1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2#doc_chap2 WKR, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] New Developer: codergeek42
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, please help me to welcome Peter Gordon aka codergeek42, our latest addition to the ranks of Gentoo Developers. And someone please explain to him how to secure his bum in SpanKY's immediate vicinity ;-) Peter is a global moderator in the Gentoo forums and for further introduction I'll let him speak himself: "I'm a 19 year old caffeine-addicted geek, living in Anaheim, California. I'm in my second year of college (full-time student) and I've been using Linux for almost three years (since Feb 2003); Gentoo since mid-2004. I greatly enjoy science fiction and consider myself somewhat of a "Trekkie;" as well as spending time with friends and family. You'll never find me without a recent copy of Knoppix. ;-) Along with this, I work full-time for a microelectronics research & development firm, helping manage inventory control and various clerical duties. I also am a big fan of the GNU project and the Free software ideologies it puts forth." Welcome Peter! Danny - -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDsBORaVNL8NrtU6IRAm3SAKCCI/h2dUunDSPS7WlE8CXrmbTDRwCgjjAv JPA1b/iQML4Bdq34jcNUOtM= =s+M0 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Mon, 26 Dec 2005 00:09:57 -0500 Doug Goldstein <[EMAIL PROTECTED]> wrote: | the USE defaults are a bit INSANE... We need to get rid of some of | this crap... No, you just don't understand how they work. It's not an issue of "is foo important". It's an issue of "for packages with optional foo support, does it make most sense for foo to be enabled by default?". Remember that, by tradition, our default USE flag setup is for desktop systems on archs where desktops are available. If you'd rather have a server-like setup, persuade your arch team to introduce sparc-style server profiles. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] New developer: hd_brummy
Welcome aboard and have a good time! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
and my bad. I am not yet awake. It died cause of runpaths on strict, it just showed both, and I wasn't thinking when I sent earlier email... On 12/26/05, Dan Meltzer <[EMAIL PROTECTED]> wrote: > On 12/26/05, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: > > On Monday 26 December 2005 13:59, Simon Stelling wrote: > > > > Actually "stricter", and there are way too many people to put that in > > > > without knowing what that do... or is it a default nowadays, I'm not > > > > even > > > > sure. > > > You're mixing up 'strict' with 'stricter'. > > Well if I'm mixing up, someone moved the QA checks from stricter to strict > > lately ;) > > I don't run strict as I usually have modified ebuilds if I'm working on > > them; > > I don't run stricter as lot of packages that fails are not mine, I usually > > use it only when I'm testing my packages or my changes. > > strict is in make.defaults... > This causes packages with executable stacks to die, and fairly > arbitrarily imo (with portage 2.1_pre2 that is) (see bug 116611). > > IMUO, portage should never die when an issue of questionable merit > comes up and features are simply those set by default. > > > > > > -- > > Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ > > Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE > > > > > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On 12/26/05, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: > On Monday 26 December 2005 13:59, Simon Stelling wrote: > > > Actually "stricter", and there are way too many people to put that in > > > without knowing what that do... or is it a default nowadays, I'm not even > > > sure. > > You're mixing up 'strict' with 'stricter'. > Well if I'm mixing up, someone moved the QA checks from stricter to strict > lately ;) > I don't run strict as I usually have modified ebuilds if I'm working on them; > I don't run stricter as lot of packages that fails are not mine, I usually > use it only when I'm testing my packages or my changes. strict is in make.defaults... This causes packages with executable stacks to die, and fairly arbitrarily imo (with portage 2.1_pre2 that is) (see bug 116611). IMUO, portage should never die when an issue of questionable merit comes up and features are simply those set by default. > > -- > Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ > Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Installing COPYING or LICENSE files
On Monday 26 December 2005 14:57, Drake Wyrm wrote: > You're going to be hard-pressed to get any kind of consensus on this > issue. Many dev seems to feel that the license belongs there. In some > cases the COPYING, LICENSE, and/or INSTALL files contain, not boilerplate > drivel, but actually unique, useful information. Removing these files and relying on LICENSE=foo in the ebuild could be seen as a copyright violation. There are lots of samples in /usr/src/licenses that aren't generic, but include a copyright notice naming the authors of a particular piece of software, but it doesn't match with all packages under this license of course. Take ZLIB as example. Since I'm not a lawyer I might be wrong, but me thinks it would make sense to ask one. Carsten pgpKKf9Ol6eov.pgp Description: PGP signature
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 13:59, Simon Stelling wrote: > > Actually "stricter", and there are way too many people to put that in > > without knowing what that do... or is it a default nowadays, I'm not even > > sure. > You're mixing up 'strict' with 'stricter'. Well if I'm mixing up, someone moved the QA checks from stricter to strict lately ;) I don't run strict as I usually have modified ebuilds if I'm working on them; I don't run stricter as lot of packages that fails are not mine, I usually use it only when I'm testing my packages or my changes. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpsZyuWhdqN2.pgp Description: PGP signature
Re: [gentoo-dev] Installing COPYING or LICENSE files
On Monday 26 December 2005 15:02, Petteri Räty wrote: > It's just that usually the > INSTALL file is not really useful unless you are manually installing the > package from sources and then you will have the INSTALL file in there > with the sources. Yeah, and in that case I usually judge it useless and avoid installing it. For the (rare) exceptions, I'd rather newdoc it with another name such as SETUP or something like that, would probably also help users to find useful informations. I'd add ABOUT-NLS files to the list of useless, as that usually just reflect the status of GNU project translations on a given gettext release... I'd rather just see it installed by gettext package itself. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpZNe63wlzLQ.pgp Description: PGP signature
Re: [gentoo-dev] Stepping aside...
The GDP does very good work and i think you did your part to make this happen. Thanks! On Fri, Dec 23, 2005 at 04:44:28PM +0100, Sven Vermeulen wrote: > With kind regards (yes, that's what "Wkr" stands for), Wkr, too :-) Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpsmioZ96jed.pgp Description: PGP signature
Re: [gentoo-dev] Installing COPYING or LICENSE files
Drake Wyrm wrote: > Petteri R??ty <[EMAIL PROTECTED]> wrote: > >>Petteri R??ty wrote: >> >>>R Hill wrote: >>> Daniel Ahlberg wrote: >* if ebuild installs COPYING and/or INSTALL into doc. Is this actually important? There are a hell of a lot of ebuilds that fail under this rule. I'd like to start filing patches for some of the packages in this list so I'm interested in knowing what's worth fixing and what's being pedantic. >>> >>>Not a blocker but just useless. Filing patches for ebuilds doing this is >>>greatly appreciated by at least me. >> >>https://bugs.gentoo.org/show_bug.cgi?id=113680 >> >>So is there a policy about [not] installing the COPYING or LICENSE files >>already? If there isn't one, I propose we make a decision about this to >>have uniform behaviour across the tree. > > > You're going to be hard-pressed to get any kind of consensus on this > issue. Many dev seems to feel that the license belongs there. In some > cases the COPYING, LICENSE, and/or INSTALL files contain, not boilerplate > drivel, but actually unique, useful information. > > Certainly there could be value in leaving out _yet_another_ copy of the > GPL and the banal INSTALL, but even that wouldn't justify a universal > ban on certain file names. > I am not out to ban certain file names. Just for example the copies of GPL-2 or the general INSTALL file. If the file does contain useful information I am all for installing it. It's just that usually the INSTALL file is not really useful unless you are manually installing the package from sources and then you will have the INSTALL file in there with the sources. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Installing COPYING or LICENSE files
Petteri R??ty <[EMAIL PROTECTED]> wrote: > Petteri R??ty wrote: > > R Hill wrote: > >>Daniel Ahlberg wrote: > >>>* if ebuild installs COPYING and/or INSTALL into doc. > >> > >>Is this actually important? There are a hell of a lot of ebuilds that fail > >>under this rule. I'd like to start filing patches for some of the packages > >>in > >>this list so I'm interested in knowing what's worth fixing and what's being > >>pedantic. > > > > Not a blocker but just useless. Filing patches for ebuilds doing this is > > greatly appreciated by at least me. > > https://bugs.gentoo.org/show_bug.cgi?id=113680 > > So is there a policy about [not] installing the COPYING or LICENSE files > already? If there isn't one, I propose we make a decision about this to > have uniform behaviour across the tree. You're going to be hard-pressed to get any kind of consensus on this issue. Many dev seems to feel that the license belongs there. In some cases the COPYING, LICENSE, and/or INSTALL files contain, not boilerplate drivel, but actually unique, useful information. Certainly there could be value in leaving out _yet_another_ copy of the GPL and the banal INSTALL, but even that wouldn't justify a universal ban on certain file names. -- In the depths of my heart, I can't help being convinced that my fellow men, with a few exceptions, are worthless. -- Sigmund Freud pgpPO0zVfXDXT.pgp Description: PGP signature
Re[2]: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
26.12.2005, 14:28:12, Jason Stubbs wrote: > On Monday 26 December 2005 20:01, Jakub Moc wrote: >> >> Currently there are quite a few ebuilds in the tree that execute dodoc >> >> or dohtml for files that do not exist. I think it would be nice to have >> >> ebuilds die if this is the case. To not break current ebuilds this would >> >> only happen with FEATURES="stricter". >> >> Sigh... There are already bugs flowing in for TEXTRELs/executable stacks >> checks implemented in recent portage versions. Some of these bugs are >> completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc. >> etc. > Sigh... None of these issues have made there way to dev-portage. > -- > Jason Stubbs Well, then assign Bug 116499 or Bug 116602 to yourself (qemu), there're textrels in openoffice-bin, mozilla-firefox-bin (upstream, don't hold your breath to get this fixed), acroread (cantfix really), this for sure will be an issue for many games binaries, etc. While it's often upstream/cantfix, I don't see much sense in making these QA checks fatal really. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpmuHTx23Adq.pgp Description: PGP signature
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 20:01, Jakub Moc wrote: > >> Currently there are quite a few ebuilds in the tree that execute dodoc > >> or dohtml for files that do not exist. I think it would be nice to have > >> ebuilds die if this is the case. To not break current ebuilds this would > >> only happen with FEATURES="stricter". > > Sigh... There are already bugs flowing in for TEXTRELs/executable stacks > checks implemented in recent portage versions. Some of these bugs are > completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc. > etc. Sigh... None of these issues have made there way to dev-portage. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Installing COPYING or LICENSE files
Petteri Räty wrote: > R Hill wrote: > >>Daniel Ahlberg wrote: >> >> >> >>>* if ebuild installs COPYING and/or INSTALL into doc. >> >> >>Is this actually important? There are a hell of a lot of ebuilds that fail >>under this rule. I'd like to start filing patches for some of the packages in >>this list so I'm interested in knowing what's worth fixing and what's being >>pedantic. >> > > > Not a blocker but just useless. Filing patches for ebuilds doing this is > greatly appreciated by at least me. > > Regards, > Petteri https://bugs.gentoo.org/show_bug.cgi?id=113680 So is there a policy about [not] installing the COPYING or LICENSE files already? If there isn't one, I propose we make a decision about this to have uniform behaviour across the tree. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: $BUILDDIR in ebuilds
Brian Harring <[EMAIL PROTECTED]> wrote:
>
> On Mon, Dec 26, 2005 at 02:51:26AM -0500, Michael Sterrett -Mr. Bones.- wrote:
> > Like in here?
> >
> > app-doc/halibut/halibut-0.9.ebuild: BUILDDIR="${S}/build" \
> > net-dns/maradns/maradns-1.0.27.ebuild:BUILDDIR=${S}/build \
> > net-dns/maradns/maradns-1.0.32.ebuild:BUILDDIR=${S}/build \
[snip]
> Either way, those 3 are fine- they're not relying on portage provided
> BUILDDIR var, just issueing a directive to make.
In that case, shouldn't they use something like BUILDDIR="$BUILDDIR" to
supply the argument to make?
--
That is not dead which can eternal lie,
And with strange eons even death may die.
-- The Call of Cthulu, II. The Tale of Inspector Legrasse
pgpxhWDidOdq5.pgp
Description: PGP signature
[gentoo-dev] New developer: hd_brummy
Hi all. Jörg Bornkessel (hd_brummy) hails from Berlin, Germany and joined the Gentoo team about two weeks ago to help with Video Disk Recorder related ebuilds. Outside Gentoo Jörg is self-employed, doing webdesign and fixing computers. Jörg also enjoys spending time with his Harley motorcycle. Please welcome Jörg to the team. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Bastiaan Visser wrote: > On Monday 26 December 2005 09:33, Mike Frysinger wrote: > >>On Monday 26 December 2005 02:24, Doug Goldstein wrote: >> >>>well there is always USE enabling... (i.e. When I emerge x11-libs/qt, >>>it'll turn on the "qt" USE flag) >> >>which we've already established quite clearly as something we wish to get >>rid of completely >>-mike > > > aint it worth it to mention "-*" in the handbook ? And then mentioning stuff like pam that almost everyone wants? There are also things that should be on by default. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
Diego 'Flameeyes' Pettenò wrote: I'm not sure if we're on the same page as far as the target audience of this change. The target audience is developers/those with strict in their features. Actually "stricter", and there are way too many people to put that in without knowing what that do... or is it a default nowadays, I'm not even sure. You're mixing up 'strict' with 'stricter'. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
Jakub Moc wrote:
>
>>>Currently there are quite a few ebuilds in the tree that execute dodoc or
>>>dohtml for files that do not exist. I think it would be nice to have
>>>ebuilds die if this is the case. To not break current ebuilds this would
>>>only happen with FEATURES="stricter".
>
>
> Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
> checks implemented in recent portage versions. Some of these bugs are
> completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
> etc. What's the point of this breakage? Why are these QA checks fatal,
> causing ebuilds to bail out? How can you disable such checks per-ebuild
> (AFAIK - you can't) to not annoy users with QA notices and breakage one can
> do nothing about anyway?
>
> As Flameeyes pointed out, dodoc/dohtml is also used in eclasses. This can
> break many ebuilds. Users will report duplicate bugs because they will not
> realize that it's the eclass causing the failure, not the ebuild. Again,
> what's the point? How will it work with FEATURES="nodoc"? Why should an
> ebuild ever fail just because some doc file is missing or got renamed or
> whatever?
>
>
echo "dodoc: ${x} does not exist" 1>&2
This should not be showed to users then because we know this to happen
and do not want to do anything about it. Also try to remember that not
every package is done following the GNU conventions (Java). It can
happen that the doc files are for example renamed and dieing will help
catch this. dodoc/dohtml dieing will not have any affect on
FEATURES="nodoc".
How about making it possible to tell dodoc/dohtml not to die as an
argument/variable/whatever? We could also have new diedodoc functions,
but it would be nice to keep this as simple as possible.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jakub Moc schrieb:
|
|>>Currently there are quite a few ebuilds in the tree that execute dodoc or
|>>dohtml for files that do not exist. I think it would be nice to have
|>>ebuilds die if this is the case. To not break current ebuilds this would
|>>only happen with FEATURES="stricter".
|
|
| Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
| checks implemented in recent portage versions. Some of these bugs are
| completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
| etc. What's the point of this breakage? Why are these QA checks fatal,
| causing ebuilds to bail out? How can you disable such checks per-ebuild
| (AFAIK - you can't) to not annoy users with QA notices and breakage
one can
| do nothing about anyway?
You can disable them. Have a look at dyn_install in ebuild.sh.
There are 2 categories of such QA violations:
* One category (qa_sucks_for_sure) currently only consists of ebuilds
~ that have run-paths pointing to a subdir of ${BUILDDIR}. Such bugs can
~ always be fixed (as it never affects binary packages) and thus this
~ category of bug lets the build process always die.
* The other category (qa_kinda_sucks) only causes the death of the build
~ process when the user has FEATURES="stricter" and the ebuild doesn't
~ have RESTRICT="stricter".
The obvious solution for unfixable (binary) packages is to set
RESTRICT="stricter" for them. On the other hand, some binary UPSTREAMs
are very kind and competent to handle such bugs if you tell them. AMD
for example, who will fix an "exectuable stack" problem in ACML after
the holidays.
Danny
- --
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDr+j8aVNL8NrtU6IRAq0kAJ92IHWPU/WRRzj5F807yU+89bm87gCfbbBF
lkpmuU3EgpaFHfaCaiShQxI=
=drQA
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
Diego 'Flameeyes' Pettenò wrote: > On Monday 26 December 2005 03:28, Chris White wrote: > >>I'm not sure if we're on the same page as far as the target audience of >>this change. The target audience is developers/those with strict in their >>features. > > Actually "stricter", and there are way too many people to put that in without > knowing what that do... or is it a default nowadays, I'm not even sure. > When I asked about stricter the first time, the response was that it is meant as a developer tool only so it will not be on by default any time soon. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doug, Doug Goldstein schrieb: |>>the USE defaults are a bit INSANE... We need to get rid of some of this |>>crap... Buzzwords like "Stupid,INSANE,crap,bitching" beside: There are projects which need these combinations of USE flags like Releng. They are currently used to create the GRP set, and I don't see them growing useless for us. Further on, the default flags are only a proposal. Nobody forces you to use them... |>not really a useful endeavor unless we get something like per-package USE |>defaults or useflag groups and a (even more) flexible profile system. |>everyone has their own opinion as to what a 'good' or 'sane' default is and |>debating each flag is a waste of energy Full ACK | oh, I also forgot to bitch about "fortran" as the crowd in #-dev pointed This has a purpose: There are a lot of packages in the tree which need a proper FORTRAN compiler installed (not f2c). Without the default fortran USE flag, people who use the GRP wouldn't be able to emerge them w/o recompiling gcc. As soon as USE based atoms are available, the Scientific Project will discuss removing "fortran" from the default USE. Danny - -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDr+XOaVNL8NrtU6IRAk/eAJ9TYUeD0n3fR6JnXRfNjddxN5+K9ACfdStW nXBlTdx89R6zdkn2wnbSiGU= =GwyL -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 03:28, Chris White wrote: > I'm not sure if we're on the same page as far as the target audience of > this change. The target audience is developers/those with strict in their > features. Actually "stricter", and there are way too many people to put that in without knowing what that do... or is it a default nowadays, I'm not even sure. > I've always found dodoc should > be checked anyways, and if we're assuming the documentation consists of the > formentioned items, then we're also having the situation of missing other > important documentation as well. Take KDE-related packages.. a good 90% of those have just the files I named or a subset of them as documentation, for those, the eclass already take care of them definitely. When there's something _more_, it can be dodoc-ed by hand. But it would fail if someone didn't put a NEWS file or a ChangeLog ... that seems stupid to me. Also, I think jakub is totally right with this. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpLC1euV5lJJ.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Doug Goldstein wrote: the USE defaults are a bit INSANE... We need to get rid of some of this crap... ./default-linux/x86/2005.0/make.defaults:USE="alsa apm arts avi berkdb bitmap-fo nts crypt cups eds emboss encode fortran foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl tcpd truetype truetype-fonts type1-fonts vorbis X xml2 xmms xv zlib" Examples include... WHY is "arts" turned on... There's absolutely no reason for it. AFAIK, you can even build KDE without it. Why are we turning "gnome" on... who says you want to pull in the damn desktop? "eds"... very very very specific Gnome app that most people don't want support for. If I remember correctly, this was added cause someone was too lazy to do the right work around in the ebuild. "gtk" and "gtk2", I thought we cleaned up this mess of just 1 USE flag. But seriously, why are these on? "kde", uh same reason and Gnome above... "ogg", "oggvorbis", "vorbis"... I thought we cleaned up this mess... I didn't bitch enough to remove oggvorbis. please update your ebuilds... lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing
Alle 13:50, sabato 24 dicembre 2005, Peter ha scritto: > Also, I find it absolutely fascinating that the only people against this > concept are devs, and the only people for it are users. Remember that > users are your customers. Every effort should be made to keep them happy. As a user, I wouldn't normally write to this list, but you asked for our opinions. Apart from the fact that I upgrade the kernel more often than I upgrade nvidia-kernel, and as many have pointed out this means reistallyng glx, nvidia-settings and nvidia-xconfig even if not needed, there's also another important point: This unified ebuild will lead me to upgrade the package even if it is just a rev-bump for issues related to (e.g.) nvidia-settings, which I don't even use!! Or do you expect that users always look at the Changelog to see if the upgrade really applies to them. How could this "improve the user's experience"? Some may not agree with the idea of turning it in a meta-ebuild, but if this must really be done, I think that would be the only way to keep everyone satisfied. -- Move -- Proudly abusing Gentoo Base System version 1.12.0_pre12 Linux 2.6.14-gentoo-r5 -- gentoo-dev@gentoo.org mailing list
