Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files
Hello, On Sun, 25 Apr 2010 13:18:25 +0200 Angelo Arrifano mik...@gentoo.org wrote: Hello developers developers and developers, Ever wondered how much crap is left in your X-years old Gentoo box? I just developed a python utility to efficiently find orphaned files in the system. By orphaned files I mean the files that are present on system directories and don't belong to any installed package. The package builds a virtual filesystem (cache) on the RAM using python hash tables. Then it uses the cache to find the ownership of files inside user-specified dirs. Building the cache takes less than 10 seconds here in a system with 1366 installed packages. This is not intended to be a finished program yet, I'm looking forward for your constructive commentaries. There is a tool that does that, qfile from app-portage/portage-utils. Check the -o, --orphans* List orphan files option. It's not as straight forward as it could be, as it checks only for files specified as arguments or read from file. But you can trivially use it like: # find /dir/you/want/to/check/for/orphans | qfile -o -f - Best, Yuri.
Re: [gentoo-dev] LICENSE and revbumps
On Wed, 27 Aug 2008 08:10:06 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: Should LICENSE changes require a revision bump? No, since it would be a waste of users' resources. For example, if a dev has missed a change from GPL-2 to GPL-3 (which I guess is a common case), would you really have users reinstall the package in this case? What would be the benefit? As an example, the user is developing a program under a licence compatible with GPL-3 but incompatible with GPL-2, he wants to extend it with the functionality provided by this library (lets assume the package in question is a library) and he is considering to statically link some bits from it. Now he can do the right way and read the whole web page from that package and learn all about it and all the other candidates, or just first apply a quick filter by checking the LICENCE file and then decide to look for another candidate. I personally would would go with the filtering approach to narrow my search and reduce the time I need to spend looking. As Another example, the user might statically link bits of the exact same library against a GPL-2 (not a GPL-2 or latter) program, just because he is misinformed by portage that the program is GPL-2 and then he gets into a legal problem. so, my point is that licences are very important in some environments and to some people, and having an inconsistently can cause serious legal problems to users. So it is very important to keep them in sync in all tree of upstream, portage tree and vdb tree. Yuri.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
Hi, On Tue, 26 Aug 2008 13:40:36 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: I'm doing some research on our usages of the $Header$ keyword in our main CVS repo. Q: Are there any other use-cases you have and actively use? I use the revision present in the header to identify changes in ebuild files that didn't needed a revision dump. Kindest regards, Yuri.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, 26 Aug 2008 13:54:21 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 03:41:07PM -0500, Yuri Vasilevski wrote: I'm doing some research on our usages of the $Header$ keyword in our main CVS repo. Q: Are there any other use-cases you have and actively use? I use the revision present in the header to identify changes in ebuild files that didn't needed a revision dump. Err, what do you mean by revision dump? revision dump is when foo-1.0-r4 becomes foo-1.0-r5. But when foo-1.0-r4 is updated in-place, I use CVS revisions (ej: 1.12 - 1.13 in 2nd word in $ Header: ) Yuri.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, 26 Aug 2008 14:45:25 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote: Err, what do you mean by revision dump? revision dump is when foo-1.0-r4 becomes foo-1.0-r5. That's revision 'B'ump, not 'D'ump. Sorry, not native English speaker :$ But when foo-1.0-r4 is updated in-place, I use CVS revisions (ej: 1.12 - 1.13 in 2nd word in $ Header: ) The $Header$ is filled out automatically by CVS, what are you using the $Header$ string for? Why do you need to identify the changes? Considering that the checksum changes as well, is detecting change not sufficient? (or asking the VCS for what files have changed since your last check time). I am writing a tool that creates deb (as in Debian package format) based distributions from gentoo packages and that tool encodes the CVS revision as part of debian revision of the packages. So I need this part to be chronologically ordered, as opposed to have only the knowledge of whenever the file has changed or not.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, 26 Aug 2008 15:25:16 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote: Why do you need to identify the changes? Considering that the checksum changes as well, is detecting change not sufficient? (or asking the VCS for what files have changed since your last check time). I am writing a tool that creates deb (as in Debian package format) based distributions from gentoo packages and that tool encodes the CVS revision as part of debian revision of the packages. So I need this part to be chronologically ordered, as opposed to have only the knowledge of whenever the file has changed or not. I'd call that critically dangerous in missing some changes. If I have a file in $FILESDIR, and change it, but it has the same name, there is no commit to the ebuild, and your .debs won't pick up changes at all. This is usually for cases with compile fixes that don't need revision bumps at all, but sometimes there are also changes to scripts. Yes, I know that this will not protect me against changes in a file from ${FILESDIR} nor a change in a file in ${A}, but that was the best way I could think of to make debian source packages (I create as well) as reproducible as possible. For the source packages I create a debian/rules[1] file that basically calls ebuild foo.ebuild with the right options and to compile and then install to a temporary directory and then call some debhelper scripts to turn that directory into a proper .deb package. So from my perspective the .ebuild file can be considered part of the debian/rules files and because of that I really need to keep track of changes in it. And for the rest of files, I bump ( :-D ) another revision counter with each rebuild of the same debian source package version, so until I find some better way to catch changes in any bit of the source (be it the ebuild, files from ${A} or files from ${FILESDIR)/) I still don't have conflicts. If you're making binary package .debs, I gather that you are grabbing the (pre|post)(inst|rm) and setup blocks for inclusion? Yes, I certainly do. That is an interesting use case, and would that would present a problem with any VCS migration. - Under SVN, you'd only have the global revision, which might not uniquely identify the file. - Bzr doesn't support keyword expansion in any released version. There are/were plans for it in 1.7, but I haven't seen anything since the first prototype. - Hg supports it with an extension: http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension But has warnings about why it sucks http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan See the 'keyword update intervals' item (mainly having to touch every file in the repo sometimes). - Git supports only the $Id$ keyword, and expands it to the SHA1 of the file, which ends up being a duplicate of the information we have in the Manifest. I am aware about this problem, and unless this is explicitly taken into consideration on migration, I guess I'll have to keep a local database of order of ebuilds as part of the metadata associated with each distribution my tool creates. [1] debian/rules files is a make file that provides the right targets for debian tools call it and generate deb binary packages. So it is kind of the equivalent of .ebuild scripts for debian.
Re: [gentoo-dev] LICENSE and revbumps
On Tue, 26 Aug 2008 20:17:48 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Should LICENSE changes require a revision bump? A licence changes what get's installed, ok the files are the same, but the meaning of having the same files is different. So I say yes. It kinda seems to me the answer should be yes. I don't know if any PM currently implements LICENSE filtering so there may not be any technical reason for it yet. And so I guess it comes down to a philosophical question - what determines the licence(s) a currently installed package is covered by? My thought is that this would be the value in /var/db/pkg/${P}/LICENSE, being the LICENSE value at install time, and therefore a change in the tree requires reinstallation to change that value. Correct. On the other hand, it also seems completely ridiculous from a practical POV to have to wait 30 days (and waste arch team resources) to fix an incorrect licence on a stable package. I think it should be sensible to make the stabilization request a lot earlier specifying the reason behind the creation of that newer revision in the bug and the stabilization process should be pretty much automatic, without wasting to much time from arch teams. On the other hand, I think it would be wise to create an explicit exception for this case in stabilization rules and to allow the uploader of the corrected ebuild to keep the same KEYWORDS instead of downgrading them to unstable. Kindest regards, Yuri.
[gentoo-dev] FRC: debtools herd creation
Hello All, I will be adding some debian build tools to the tree, and would like to create the debtools herd to associate with the packages. I'll be adding things like debhelper, lintian and a little bit later things like apt, aptitude, cdebootstrap, debian-live and some more. Also there is debootstrap with [EMAIL PROTECTED] which I'd like to adopt. Any comments, sugestions and objections are more than welcome. Kindest regards, Yuri. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] debianutils: system worthy ?
On Mon, 28 Jan 2008 07:23:18 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: now that the mktemp binary has been moved out of debianutils and integrated straight into coreutils, perhaps it's time to ask how important this package is to everyone. current debianutils is part of system and provides: - installkernel - run-parts - tempfile - savelog - mkboot do people consider these things critical ? i dont know the last time i personally needed/wanted any of these ... I would say drop it from system and add to RDEPEND in kernel-2.eclass for ${ETYPE} == sources. Kindest regards, Yuri. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] USE flag documentation
Hello, On Sun, 13 Jan 2008 20:24:53 -0500 Mark Loeser [EMAIL PROTECTED] wrote: What exactly do we need this system to do that we can't do now? The only interesting thing I can think of, is to expose some of the USE flags logic found in some ebuilds in a parseable fashion. I'm talking about things like (from mplayer-1.0_rc2_p24929-r2.ebuild): - Two flags are mutually exclusive: ( cdio implies !cdparanoia ) and (cdparanoia implies !cdio) - A flag makes sense only if another flag is on: !encode implies !aac This way portage will be able to inform/warn the user automatically that the set of USE flags the user has chosen really means some other thing. Something like: [ebuild R ] media-video/mplayer-1.0_rc2_p24929-r2 USE=X cdio -aac#1 -cdparanoia#2 -encode ... #1 aac needs encode #2 cdio conflicts with cdparanoia But this logic will have to be exposed on a .ebuild level. Is overriding the USE flag with use.local.desc sufficient and we just need to document the current solution properly? I would say yes. Also, what would we gain switching to xml? The format as it is now is trivially parseable and human friendly. While if the data is in xml format it will be less human friendly, as well as, it will be harder to extract the information from shell scripts. Kindest regards, Yuri. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [GLEP] RFC - Keywording scheme
On Wed, 25 Apr 2007 23:39:47 +0200 Rémi Cardona [EMAIL PROTECTED] wrote: Grant Goodyear a écrit : Fabian Groffen wrote: [Sat Apr 14 2007, 03:33:03AM CDT] For people that like reading it in html or via the web: http://dev.gentoo.org/~grobian/gleps/glep-keywords.html http://dev.gentoo.org/~grobian/gleps/glep-keywords.txt So what would a version of Gentoo for amd64 based on FreeBSD but using glibc be called? (It's not an entirely academic question; Debian folks have worked on such a distribution for some time.) I can't really tell from the text in your proposed GLEP. I'm sure this GLEP can be extended later on should anyone feel like doing a glibc-based freebsd port of gentoo (hurts my brains just writing this :) ) I think it will be better if this scheme is specified in friendlier way for future expansions, hence I this it should be more flexible. I would propose this two modifications: (a) Instead of using n-tuples to describe a keyword, to use sets. Both ways can be made semantically equivalent if we add the restrictions that the sets of all the possible architecture, kernel, userland, libc, ... sub-keywords are disjoint. (i.e. If there is a userland sub-keyword bsd, then there can't be a kernel or libc sub-keyword named bsd, they have to be named in a slightly different way.) But on the other hand, the notation will be way more flexible as a keyword can only specify the relevant sub-keywords, while the rest can be considered to be a wildcard (to mean all) (b) In case there are several keywords A and B: - if A is more specific that B, A takes precedence (ej. with !uclibc arm:uclibc the package can be installed on any system that does not uses uclibc as libc or on any system with arm hardware.) - if A is exactly as specific as B, the union of A and B is used (ej. !uclibc arm this is equivalent to the previous example.) So to give more examples, A package that can only be build on arm, sparc and x86 with linux and glibc or arm with uclibc can be specified as: {arm,sparc,x86}:linux:glibc arm:uclibc A package (lets say linux-headers) that makes sense on all systems that support linux and only them can be specified as: linux A package that is stable with gnu userland but still in testing with bsd userland: {some,arches}:gnu ~{some,arches}:bsd or just gnu ~bsd for all arches. Note that I propose to mark testing the whole set of sub-keywords, not just like I run stable x86 with unstable bsd as I think it does not make any sense as the resulting combination is still considered unstable/testing. There are two things I see against my proposal: - This is not fully backward compatible, as it is currently equivalent to normal arch keywords if the user runs linux with glibc/uclibc, while it has a completely different meaning for Gentoo/Alt users. But I don't see it as a big problem because, as far as I understand, this will be just one of many changes that need to be made to make Gentoo/Alt as integrated as GNU/Linux is now into portage. - For this to work, the keyword resolver will have to be way more complex than it is now, as it will have to compute the subset of all possible keywords some ebuild defines to see if user's accept keywords intersect it. Kindest regards, Yuri. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, 20 Apr 2007 14:52:46 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: On 20-04-2007 15:45:00 +0300, Petteri Räty wrote: I use it to make deltas of changes made in the tree, and apply those deltas on the overlay I'm using. Without $Header: $ there I have no way to actually see which version I'm dealing with, so which revisions to retrieve for differences. For that reason, I prefer as much files as possible in the tree to have a $Header: $ somewhere, so I can easily sync, keeping my local changes. Is the info you need in CVS/ ? That requires: a) an up-to-date CVS tree checkout b) a CVS tree (not a regular rsynced one) c) parsing of the CVS/Entries file So in principle, yes I think it can be done using the CVS directory, but I prefer not to. +1 on this one. I am writing some script to automate package building and use the Header field to detect CVS revision changes. I know I could do it with hash values, but then it would be harder to have builds from different revisions of the same ebuild file time ordered. Best, Yuri. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
On Mon, 12 Mar 2007 16:36:03 -0700 Ned Ludd [EMAIL PROTECTED] wrote: And matches $(which x11-misc/xoo/xoo-0.7.ebuild:25: Fixed. Best wishes, Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GPL-2 vs GPL-2+
Hi, On Fri, 22 Dec 2006 21:56:54 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: At the moment we represent the software we consider under GNU General Public License, version 2 of the license, but we cannot be sure it's alright to license it to any later version. Linux kernel for instance is licensed _only_ under GPLv2, but not any later version. I don't think this is a good solution, as in any case the package is licensed under GPL-2, so how about for the packages that only support GPL-2 we set: LICENSE=GPL-2 While for the ones that support v2 or later (this is actually a special case of multiple licensing) we do: LICENSE=GPL-2 GPL-3 when it becomes available? Best, Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GPL-2 vs GPL-2+
On Fri, 22 Dec 2006 17:06:32 -0500 Alec Warner [EMAIL PROTECTED] wrote: Yuri Vasilevski wrote: Hi, On Fri, 22 Dec 2006 21:56:54 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: At the moment we represent the software we consider under GNU General Public License, version 2 of the license, but we cannot be sure it's alright to license it to any later version. Linux kernel for instance is licensed _only_ under GPLv2, but not any later version. I don't think this is a good solution, as in any case the package is licensed under GPL-2, so how about for the packages that only support GPL-2 we set: LICENSE=GPL-2 While for the ones that support v2 or later (this is actually a special case of multiple licensing) we do: LICENSE=GPL-2 GPL-3 If you meant: LICENSE= || ( GPL-2 GPL-3 ) then I agree ;) It would be under Either the GPL-2 OR a later version, not both, yes? Right, thanks for catching that. Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GPL-2 vs GPL-2+
On Fri, 22 Dec 2006 23:31:04 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: On Friday 22 December 2006 22:53, Yuri Vasilevski wrote: While for the ones that support v2 or later (this is actually a special case of multiple licensing) we do: LICENSE=GPL-2 GPL-3 when it becomes available? There is one problem at least for this: to apply this method you'd have to change _all_ the ebuilds in the tree referring to GPL-2 or later when GPL-3 is published, while with GPL-2+ we can start gradually now. Yes, this will require us to update ebuils once in like 5 (or 15?) years to catch with FSF. But at the benefit of having less confusion for users about What the heck is a GPL-2+? for at last the same period of time. GPL-2 is not a licence nor it is not a standard notation for that way of having multilicencing. So users will have to check what's the meaning of that + at the end of GPL-2+, so I think it'll create much more confusion than the work of updating packages with each new version of GPL. Also there could be a case that softer v3 is out, FSF will rethink and come up with something acceptable to Linus (and other people that refuse to migrate), as (as far as I can understand) GPL-3 will not be compatible with GPL-2. So there could be the case of having a package licenced under GPL-2, GPL-2.1 or later. (This is just an example, I actually have no idea whatever this will be the case of having a softer GPL-3.x.) Also it would be more useful for users to know what can be licensed in 2+ and what requires 2 strictly. This info can be easily and automatically extracted from LICENSE variable by applying some boolean logic ;-) Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] portage idea - auto embed user patches
Hello, On Thu, 21 Dec 2006 17:32:41 +0300 Alexander Zubkov [EMAIL PROTECTED] wrote: Hi! I have some idea on extending portage building system (ebuild?). Sometimes I'm (for example) want to apply custom patch to some package. This patch can do something unusual, that can not be accepted by maintainers and I know this. But I like features in my patch and want it to apply automatically when updating the package. Not to do it like this: $ ebuild /usr/portage/pkg-categoty/some-package/some-package-1.0 unpack $ cd /var/tmp/portage/pkg-categoty/some-package/work/... $ patch -p1 ~/my-patch-for-some-package $ cd $ ebuild /usr/portage/pkg-categoty/some-package/some-package-1.0 merge It is lot of manual work. The idea is having an file, for example /etc/portage/package.patch with contents like this: =pkg-category/some-package-1* /path/to/my-patch-for-some-package Of course, patches could fail in newer versions. But when I'll use that feature - I'll understand why it can be and it'll be more convenient to maintain it. You can use portage's bashrc to do that kind of autopatching. Best regards, Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2006-12-17 23:59 UTC
Hi, On Mon, 18 Dec 2006 10:02:00 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: On Sun, 2006-12-17 at 23:20 -0800, Robin H. Johnson wrote: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2006-12-17 23h59 UTC. OK. Here's a fun question for you... Is it possible to have a slightly modified version of this script run, and the output sent to gwn-feedback for inclusion in the GWN? This would make my life tremendously easier, since currently I have to completely reformat this by hand. Basically, I would want the output to look like: I think it should also include the Homepage(s) and Description of the packages so readers could easily check what that additions are all about. While I'm not that sure that additions date and probably who made the addition are that important for readers. table tr thPackage:/th thAddition date:/th thContact:/th /tr tr tisci-biology/amap/ti ti11 Dec 06/ti timail link=[EMAIL PROTECTED]Donnie Berkholz/mail/ti /tr /table So I think it should be something like: table tr thPackage:/th thHomepage:/th thDescription:/th /tr tr tiuri link=http://packages.gentoo.org/packages/?category=sci-biology;name=amap sosci-biology/amap/uri/ti tiuri link=http://bio.math.berkeley.edu/amap/;Homepage/uri/ti tiProtein multiple-alignment-based sequence annealing/ti /tr /table Best, Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2006-12-17 23:59 UTC
Hi, On Mon, 18 Dec 2006 11:38:14 -0500 Alec Warner [EMAIL PROTECTED] wrote: I think it should also include the Homepage(s) and Description of the packages so readers could easily check what that additions are all about. While I'm not that sure that additions date and probably who made the addition are that important for readers. The only reason the contact and date are there is because the code for removals and additions is basically the same (A or D tells me which one it is) and all that info is available in the CVS history file. The problem with HOMEPAGE or DESCRIPTION is that they are version specific and there is no way to choose which version to pick in the case where more than one version was added at the same time. The way I implemented this was to get the homepage(s) and description from the newest version, but I think absolutely any convention will work as in the very rare cases where someone commits several versions with different homepages or descriptions, giving the info about just one of the versions should be quite a good indicator on what this package is all about, else the versions should not share the same package name (in the case that they do completely different things). Also, to get that info you can use portageq in a reasonably simple way, something like: let ebuild be $CATEGORY/$PF homepage=$(PORTDIR_OVERLAY=${CVS_DIR} portageq metadata / ebuild \ ${ebuild} HOMEPAGE) description=$(PORTDIR_OVERLAY=${CVS_DIR} portageq metadata / ebuild \ ${ebuild} DESCRIPTION) This will make the script a little bit slower, but it should not be that hard to integrate. Best, Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2006-12-17 23:59 UTC
On Mon, 18 Dec 2006 13:28:22 -0800 Robin H. Johnson [EMAIL PROTECTED] wrote: On Mon, Dec 18, 2006 at 02:53:56PM -0600, Yuri Vasilevski wrote: This will make the script a little bit slower, but it should not be that hard to integrate. Please read the message that I sent as well. In specific, there is NO way we can gaurentee that the machine has an up to date copy of the tree - thus why we use CVS history directly. Yes, sorry, my mistake. For some reason I assumed that on the CVS server you also have the tree ready to use and in an unpacked form. Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: persistence of eclasses for installed packages
On Sat, 4 Nov 2006 06:46:02 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Saturday 04 November 2006 06:14, Petteri Räty wrote: Zac Medico kirjoitti: What do people think about these two approaches? Personally, I would prefer approach #2 for the sake of simplicity and maintainability. The sooner that we start storing eclasses.tbz2 for each installed package, the sooner that we will be able to have more freedom with the eclasses in the live portage tree. One thing that comes to mind is that how do we handle the case where the old version of the eclass has a major bug in pkg_postrm for example. I think it is also possible that changes into a eclass introduce a new unexpected bug, so this shouldn't be the only reason to stop doing this. How about introducing a variable OBSOLETES=list of cvs revisions, this way it can be automatically detected if the cached ebuild/eclass can be used or if it needs to be ignored and the newer version from portage that obsoletes it has to be used? that would be the only thing keeping me from saying LETS DO #2 NOW ;) I'd vote, lets do #2 in any case. Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: put new additions along with removals in GWN
Hi, On Sat, 28 Oct 2006 19:58:09 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sat, 28 Oct 2006 20:42:14 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | Someone needs to implement the foo; however. | | (Not on cvs, but on a normal tree, but maybe works on cvs. There is a | sanity check by checking that a dir contains at least 1 ebuild) If the foo were that simple, someone would have done it long ago. It needs to take into account updates/. I have sent my script directly to wolf31o2 some days ago thinking that the exact technical details can considered spam for the majority subscribed on the list, but for completeness I'm attaching in in this e-mail. It works comparing two different portage snapshots that it can also download. Best, Yuri. gen_newpkg_table.sh Description: application/shellscript
Re: [gentoo-dev] heads up: adding ca-certificates as a PDEPEND to openssl
Hi, On Fri, 30 Dec 2005 17:34:59 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: just a heads up ... i'm going to be adding the ca-certificates package as a PDEPEND to the openssl package so most everyone in Gentoo will end up with it on their system for those wondering what this is: http://packages.debian.org/unstable/misc/ca-certificates basically it's additional certificates that arent part of the default openssl distribution I'm not so sure that this is a good idea, as adding CA root certificates is a way to make (good) money for some free projects and unfortunately for some non free ones too. I'm not sure if openssl charges certificate inclusion, but if it does this will interfere with the founding policies (and then development) of openssl. Now, being a little bit less ideological, I think it is perfectly ok to add certificates from some organizations like CACert.org that try to make security free for all Internet users as well as open source projects' certificates (like debian ones). But it should be up to businesses to buy they're way into openssl by the means of this sponsoring. So my suggestions is to add root certificates only for non for profit organizations. (For intermediate certificates that already have root certificate bundled with openssl it ok in all cases). Or at last don't make it a RDEPEND but an einfo you may want to intall X for Y reason. this will inadvertently fix this fun bug: http://bugs.gentoo.org/101457 and probably more in the future In this king of cases it is probably better to ask upstream to bug they're CA to sponsor openssl or use some free CA. Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] revdep-rebuild
Hi, On Sat, 13 Aug 2005 18:01:05 -0700 Stefan Jones [EMAIL PROTECTED] wrote: So I have started making a small C program which does the Checking dynamic linking consistency... part of the revdep-rebuild program (I think this the the most time intensive part). I think it'll be better/preferable if you make it an applet for portage-utils. Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting one source package into many binaries
Hi, On Thu, 16 Jun 2005 12:40:39 -0500 Brian Jackson [EMAIL PROTECTED] wrote: Rafael Espndola wrote: I am using Gentoo to build some small systems. While things like the minimal useflag is a joy, the monolithic nature of most gentoo packages is a headache. Kde has been spit and libstdc++ can be installed without gcc but there are many other packages that don't have this feature. For example, installing qt also installs qt designer. Use INSTALL_MASK to keep it from getting installed. Keep both pieces. I think that it's not the way to go because this will create the exact problem that existed with installing an incomplete kde before there where split ebuilds for it. And this problem is that when you emerge a package it expects it's dependencies to have the things it'll use form them. And with INSTALL_MASK you brake this assumption in a way that there is no easy way for an ebuild to verify that it's dependencies have installed the things that the package needs. So I think it may be good for some packages to be split in several packages (but right now I can't think of any), but I think it'll be much better introduce more granularity into many ebuils with use flags. This is specially the case (in my opinion) of packages that can have both client and server functionality (the best example I can think of is net-fs/samba, which I mostly use just to mount shares form other servers). Just my 2 non convertible (i.e. non developers) cents. Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Hi guys !!
Hi, On Sat, 04 Jun 2005 14:48:18 -0400 Aaron Walker [EMAIL PROTECTED] wrote: I want to know how to make ebuilds (please if you could send me the web site that explains it), http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml I suggest you to make an ebuild for wxmaxima: http://wxmaxima.sourceforge.net Bugs/new ebuilds requests go to http://bugs.gentoo.org/. http://bugs.gentoo.org/show_bug.cgi?id=83167 Best regards, Yuri. -- gentoo-dev@gentoo.org mailing list