Re: [gentoo-dev] Handling Launchpad SRC_URI
On Sat, 24 Jan 2009 23:38:32 -0800
Josh Saddler nightmo...@gentoo.org wrote:
Right now, there's no canonical (heh) way of handling SRC_URI for
projects that have their files at launchpad.net. We need a standard
way of handling Launchpad SRC_URIs, similar to what we do with
mirror://sourceforge/ SRC_URIs.
1. Some packages use the launchpadlibrarian.net download redirect,
which results in a non-helpful server-generated number:
(gnome-catalog)
SRC_URI=http://launchpadlibrarian.net/11326737/${PN}_${PV}.orig.tar.gz
2. Some hack up interesting MY_P stuff:
(gnome-do-plugins)
MY_PN=do-plugins
PVC=$(get_version_component_range 1-2)
PVC2=$(get_version_component_range 1-3)
SRC_URI=https://launchpad.net/${MY_PN}/${PVC}/${PVC2}/+download/${P}.tar.gz;
(avant-window-navigator-extras)
MY_P=awn-extras-applets-${PV}
SRC_URI=https://launchpad.net/awn-extras/${PV%.*}/${PV}/+download/${MY_P}.tar.gz;
The AWN-extras ebuild is the closest to the right way of doing it, I
think.
So can we agree on a standard way of treating Launchpad SRC_URIs and
get the handler support into Portage?
The best way would be to convince upstream to offer a simpler URL
scheme. Adding a special handler in the PM would be the worst option
(also there is no such thing atm, mirror://sourceforge/ doesn't do
anything special). The easiest option would probably be a little helper
function in eutils to generate the correct URL, if you *really* need to
simplify things (in your examples, the only sligthly odd thing are the
version parts in the URL, the MY_P stuff would be needed anyway from
what I can see).
Marius
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
On Sat, 17 Jan 2009 14:09:49 +0100 Thomas Sachau to...@gentoo.org wrote: Hi, as specified in the PMS spec [1] and stated in #gentoo-portage, RDEPEND will be set to DEPEND, if it is not defined in the ebuild itself. But devmanual [2] and developer handbook [3] both state, you have do explicitly set RDEPEND because it may be removed in the future. Since package manager have to follow the PMS spec, i would suggest to change those docs [2][3] and let them follow the PMS spec. Any problems, suggestions or anything else about this? It's strongly recommended to set both explicitly as the behavior could change in future EAPI versions, and to ensure that you actually think about which deps are build deps and which are runtime deps. Also there is nothing wrong with policies being stricter than the underlying spec. Marius
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
On Sat, 17 Jan 2009 16:41:25 +0100 Thomas Sachau to...@gentoo.org wrote: Marius Mauch schrieb: It's strongly recommended to set both explicitly as the behavior could change in future EAPI versions, and to ensure that you actually think about which deps are build deps and which are runtime deps. Also there is nothing wrong with policies being stricter than the underlying spec. If i want to use some future EAPI (give me some reasons, why this should be changed there by default), i should think about it. If nothing else, dropping the implicit assignment would remove one special case to handle in the PM (and I hope that everyone agrees that special cases should generally be avoided). In the past there have also been some issues due to the interaction between the implicit setting of RDEPEND and eclasses (long fixed, but shows that there is a bit more involved than might obvious). But most ebuilds will stay with the default. I do think about runtime deps and build deps. If you do that's good, but that doesn't mean everyone else does. Consider looking at an ebuild for a package you're not familiar with that doesn't set RDEPEND. Could mean that the author was just too lazy to add a RDEPEND=$DEPEND statement and that all deps are needed for build and runtime, or that he completely forgot to think about runtime deps. There is no way to know (without asking him) if the implicit RDEPEND is actually intended or not. In my eyes, this is similar to src_unpack and src_compile. They have defaults, noone specifies the defaults, even if they are changed in some EAPI. Sure, but the key difference is that the defaults for those are fixed. You would have a point if the default src_compile would vary based on what other phase functions the ebuild defines, but that's not the case. Marius
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
On Wed, 31 Dec 2008 10:55:39 +0100 Fabio Rossi ross...@inwind.it wrote: On Wednesday 31 December 2008, Marius Mauch wrote: Any reason for that? Aesthetics aren't a very compelling argument IMO, and the FHS also seems to favor the current layout (in my interpretation at least, as we're not really talking about inter-related applications in technical terms). I agree with you, there is no technical relation, i.e. those applications are stand-alone, but I also think that the link is their role, they are all used for administrative purposes *inside* a Gentoo distribution (inside might be the right keyword to justify a little deviation from the FHS). The same could be said about /var/lib/init.d, /var/lib/dhcp, /var/lib/iptables or several other packages that aren't hosted by Gentoo. In the other direction, if the packages are eventually used on other distributions/systems, should they then use another path? Mind that this only addresses the FHS part of my mail, you haven't really answered my question: What's the benefit of changing things? Change for the sake of change is rarely a good idea (unless you work in PR/marketing ;) In the opposite direction, in according to your opinion, I don't see a reason to have /var/lib/gentoo/news instead of something like /var/lib/gentoo-news. Right. But retroactively changing GLEP 42 and all affected packages is a bit much just to avoid a generic gentoo directory. Marius
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
On Wed, 31 Dec 2008 12:00:35 +0100 Fabio Rossi ross...@inwind.it wrote: On Wednesday 31 December 2008, Marius Mauch wrote: The same could be said about /var/lib/init.d, /var/lib/dhcp, /var/lib/iptables or several other packages that aren't hosted by Gentoo. In the other direction, if the packages are eventually used on other distributions/systems, should they then use another path? The path could be configured of course but, again, I see a few chances of having this tools outside gentoo, the proposal is based also on this idea. Mind that this only addresses the FHS part of my mail, you haven't really answered my question: What's the benefit of changing things? Change for the sake of change is rarely a good idea (unless you work in PR/marketing ;) The main benefit is a cleaner filesystem, I don't know your opinion but I hate to see sparse files around the tree and waste time in discovering their source :-) Moreover IMHO it gives me the impression of a better design. Ok, so in other word aesthetics. In the opposite direction, in according to your opinion, I don't see a reason to have /var/lib/gentoo/news instead of something like /var/lib/gentoo-news. Right. But retroactively changing GLEP 42 and all affected packages is a bit much just to avoid a generic gentoo directory. So we can exploit this condition to collect all gentoo related files inside this dir ;-) Well, the impact is about the same wether you want to change one or the other (btw, what about other admin tools on Gentoo, e.g. paludis/pkgcore, by your definition they'd also have to go into /var/lib/gentoo, right?), and that impact is non-trivial (it's not so much the code changes themselves but the inevitable transition problems). Compared to the IMO very questionable benefit of a cleaner filesystem (by hiding files users usually don't see anyway one level deeper in the tree structure) that more or less goes against the FHS, that doesn't sound like a good deal to me. Marius
Re: [gentoo-dev] Re: reorganization of /var/lib gentoo-related files
On Wed, 31 Dec 2008 16:15:54 +0100 Fabio Rossi ross...@inwind.it wrote: On Wednesday 31 December 2008, Jeremy Olexa wrote: Fabio Rossi wrote: On Wednesday 31 December 2008, Duncan wrote: Except that... in theory, some or all of those apps could technically be used on/for other distributions and platforms as well. Yes, this is the theory but I think they'll be never ported to other distributions. sabayon doesn't use these apps? How about gentoo based livecds, etc. ? Ok, you're right. But I wasn't speaking about gentoo-based distributions... Well, a few people have actually been using portage on rpm-based distros as well in the past. Granted that was usually quite a hack and required a few modifications, but it might not be as impossible as you think.
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
On Wed, 31 Dec 2008 01:12:23 +0100 Fabio Rossi ross...@inwind.it wrote: I'm proposing to reorganize the files related to Gentoo inside /var/lib. Currently we have this situation (at least on my system): /var/lib/eselect /var/lib/gentoo/enews /var/lib/herdstat/ /var/lib/module-rebuild /var/lib/portage The main dir should be something like /var/lib/gentoo, so I'd see all gentoo-related files as /var/lib/gentoo/eselect /var/lib/gentoo/enews /var/lib/gentoo/herdstat/ /var/lib/gentoo/module-rebuild /var/lib/gentoo/portage What do you think about? Any reason for that? Aesthetics aren't a very compelling argument IMO, and the FHS also seems to favor the current layout (in my interpretation at least, as we're not really talking about inter-related applications in technical terms). Marius
Re: [gentoo-dev] [RFC] Should unicode be allowed in ebuild metadata variables?
On Tue, 30 Dec 2008 09:37:24 +0530 Nirbheek Chauhan nirbheek.chau...@gmail.com wrote: On Tue, Dec 30, 2008 at 8:27 AM, Ben de Groot yng...@gentoo.org wrote: Zac Medico wrote: Nevermind, apparently GLEP 31 already requires ASCII anyway: http://www.gentoo.org/proj/en/glep/glep-0031.html The way I read that GLEP is that in ChangeLog and metadata.xml we should accept the full range of UTF-8. I read that as contents of portage tree should be in UTF-8, file paths should be in ASCII It is proposed that UTF-8 ([1]) is used for encoding ChangeLog and metadata.xml files inside the portage tree. [...]it is proposed that UTF-8 is used as the official encoding for ebuild and eclass files Patches must clearly be in the same character set as the file they are patching. Characters outside the ASCII 0..127 range cannot safely be used for file or directory names It is also worth mentioning that Python 3K uses UTF-8 as the default encoding for it's files rather than ASCII as Python 2.X did. Why should *we* go backwards? :p And none of that is relevant to Zacs original question, which is covered by the following section of the GLEP: However, developers should be warned that any code which is parsed by bash (in other words, non-comments), and any output which is echoed to the screen (for example, einfo messages) or given to portage (for example any of the standard global variables) must not use anything outside the regular ASCII 0..127 range for compatibility purposes. Marius
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
On Tue, 9 Dec 2008 11:21:24 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
On 01:44 Tue 09 Dec , Federico Ferri wrote:
today I hit this annoyance, because my laptop hung in the middle of
an 'emerge -e @world' (checking that my world set compiles with
gcc-4.3... stopped at ~ 300 of 700 :S )
I was looking for an entry in /var/db/pkg/cat/pkg/ that could have
told me the compiler used to build the package, but couldn't find
any. indeed it would be a fairly useful feature to have, both for
testing purposes, and for user's everyday maintenance.
please criticize this with anything constructive you can think of.
As I mentioned on IRC, I think this isn't a very general use case
(given the existence of --resume, --keep-going, etc.) so code to
accomplish it would be better put into a custom portage bashrc than
into portage proper.
ISTR that you could no longer resume for some reason. Perhaps what
you really wanted was a way to save the resume list across multiple
emerges?
For the given use case it might also be an option to use the AgeSet
handler in portage-2.2, e.g.
emerge -p '@old{class=dbapi.AgeSet,age=2}'
to list all installed packages that have been installed more than two
days ago.
Marius
Re: [gentoo-portage-dev] Re: equery refactorization
On Sun, 7 Dec 2008 12:44:25 +0900 Douglas Anderson [EMAIL PROTECTED] wrote: I also thought about renaming the list(l) option as search, because if you look at the help output, almost every module lists something. equery's list is actually a search, I don't see why we shouldn't name it that. I think maybe list was used because there were already two s options, stats and size. Stats is not implemented so I'm taking it out of help for now. Size can use the short z, becaues that's quite unique. That would free up s for search and it would be a whole lot clearer. Yes? No? No. search (if used at all) should be reserved for a more comprehensive search framework (though IMO a separate tool for that is more appropriate), not just a simple name match. list makes sense if you consider that the pkgspec argument is optional, and one of the main tasks of it is to simply list the packages in the given repository (that's why vardb is also the default for it) without further filtering. Also one of the main goals of equery (according to karltk, the original author) was to have a stable user interface, compared to the deprecated qpkg and etcat scripts. And while the equery interface isn't exactly the best I've seen it has been stable, so you might want to think twice before renaming options and eventually pissing off users or breaking third-party scripts. Marius
Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
On Wed, 03 Dec 2008 02:05:31 +0100 [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: metadata.xml already contains data that eix and other software should be able to search in (like longdescriptions), and having each package in kde-base report http://www.kde.org/ as its homepage is kinda pointless if you think about search, since that's not data, it's noise. So you're saying if I'm interested in a url to look for information about kalarm, I should search for it in metadata.xml of random kde packages? Sorry, but that doesn't make any sense to me. While I'm not necessarily against your primary goal here, your argumentation is very subjective to say the least (e.g. just because you find xml easier to read/parse than ebuilds doesn't mean the same holds true for everyone else, ignoring the whole cache issue). It feels a bit like you're looking for problems to justify your solution rather than the other way round. Marius
Re: [gentoo-dev] Re: debug/release builds extensions/clarification proposal
On Wed, 3 Dec 2008 08:19:18 +0100 Maciej Mrozowski [EMAIL PROTECTED] wrote: No, and I'm afraid I cannot provide any single evidence that users actually need features like: - per package cflags/ldflags/features - per category use flags, accept_keywords, cflags - or tag clouds instead of hard coded categories - user-defined packages sets (official) - multiple portage configurations support to ease building binaries for several targets on a same host - dynamic libraries tracking for safe package upgrade or removal - real backwards dependencies - maybe git driven Portage - automatic kernel modules rebuilding - mysql split ebuilds Assuming that's a list of feature requests, you know that half of them are already available, right? (not counting the non-feature in there) Marius
Re: [gentoo-dev] debug/release builds extensions/clarification proposal
On Mon, 01 Dec 2008 11:39:35 +0300 Peter Volkov [EMAIL PROTECTED] wrote: This leads me to different conclusion. I was thinking about new portage feature: emerge --info pkg . So to make portage show not only global information but per-package either. In many cases this will simplify analyzing of the problem. That feature already exists (for installed packages at least). Marius
Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official
On Mon, 01 Dec 2008 15:35:32 -0700 Joe Peterson [EMAIL PROTECTED] wrote: My intention with the RFC was to see if the concept has any worth and to kick it around a bit. I do not really see this as a deficiency in Gentoo's technology (which I have a feeling is how many here have interpreted it), but simply something that, if done correctly, could be useful. Maybe provide a real example to demonstrate the difference between the current solutions and what you're looking for, because I still don't understand what you're after (using all the different terms, logs, notes, docs, plain emerge log, ... without further explanation doesn't help much to clear things up). Marius
[gentoo-dev] Time to say goodbye
So, time has come for me to realize that my time with Gentoo is over. I haven't actually been doing much Gentoo work over the last months due to personal reasons (nothing Gentoo related), and I don't see that situation changing in the near future. In fact I've already reassigned or dropped most of my responsibilites in Gentoo a while ago, so there are just a few pet projects left to give away: - my gentoo-stats project (in the portage/gentoo-stats svn repository). I know quite a few people are interested in the idea of collecting various statistic data from gentoo user systems, and I'd encourage everyone who wants to implement such a system to at least look at it (I may have even finished it if I wouldn't have wasted my time focusing on the wrong problems). There is quite a bit of documentation also that should help to get you started - a graphical security update tool (see bug #190397) So if anyone wants to adopt those, complete or just parts, just take them. As for Portage, Zac has practically already filled my role. So I guess that wraps it up. It's been a nice ride most of the time, but now it's time for me to leave the Gentoo train. Marius
Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official
On Sun, 30 Nov 2008 09:25:51 -0700 Joe Peterson [EMAIL PROTECTED] wrote: Bottom line here is that there is extremely valuable and critical info in our emerge output. In a way, these messages are like Gentoo-specific READMEs (or release notes and/or install instructions). However, it is not saved for a user to use as a resource later (well, except that it is partially saved in the master emerge.log, but that's not quite useful enough). There is no official place to go to look for Gentoo instructions; /usr/share/doc is one logical place, but it only contains files actually installed, not the notes output by emerge (and these are usually upstream-supplied, not Gentoo). I propose that, upon merging a package, we save the emerge messages in either: 1) a package-specific file that resides somewhere official or 2) in the portage DB, so that the messages can be re-read via a portage utility. In the latter case, either a new option to equery or a new q command (e.g. equery readme pkg or qreadme pkg could retrieve the text). By default, messages generated by elog, ewarn and eerror are recorded in /var/log/portage/elog/summary.log (emerge.log is just a transaction log, so best to ignore it here). einfo isn't recorded on purpose as it isn't intended for important information (that's the purpose of elog). There are some tools available to simplify reading these messages, and there several additional/alternative delivery modules available (by mail, IM or in package specific files), customizable via POTAGE_ELOG_* variables. Don't know if you just haven't been aware of this, or if you're asking for something completely different. Marius
[gentoo-portage-dev] Time to say goodbye
So, time has come for me to realize that my time with Gentoo is over. I haven't actually been doing much Gentoo work over the last months due to personal reasons (nothing Gentoo related), and I don't see that situation changing in the near future. In fact I've already reassigned or dropped most of my responsibilites in Gentoo a while ago, so there are just a few pet projects left to give away: - my gentoo-stats project (in the portage/gentoo-stats svn repository). I know quite a few people are interested in the idea of collecting various statistic data from gentoo user systems, and I'd encourage everyone who wants to implement such a system to at least look at it (I may have even finished it if I wouldn't have wasted my time focusing on the wrong problems). There is quite a bit of documentation also that should help to get you started - a graphical security update tool (see bug #190397) So if anyone wants to adopt those, complete or just parts, just take them. As for Portage, Zac has practically already filled my role. So I guess that wraps it up. It's been a nice ride most of the time, but now it's time for me to leave the Gentoo train. Marius
Re: [gentoo-portage-dev] search functionality in emerge
On Sun, 23 Nov 2008 07:17:40 -0500 Emma Strubell [EMAIL PROTECTED] wrote: However, I've started looking at the code, and I must admit I'm pretty overwhelmed! I don't know where to start. I was wondering if anyone on here could give me a quick overview of how the search function currently works, an idea as to what could be modified or implemented in order to improve the running time of this code, or any tip really as to where I should start or what I should start looking at. I'd really appreciate any help or advice!! Well, it depends how much effort you want to put into this. The current interface doesn't actually provide a search interface, but merely functions to 1) list all package names - dbapi.cp_all() 2) list all package names and versions - dbapi.cpv_all() 3) list all versions for a given package name - dbapi.cp_list() 4) read metadata (like DESCRIPTION) for a given package name and version - dbapi.aux_get() One of the main performance problems of --search is that there is no persistent cache for functions 1, 2 and 3, so if you're just interested in performance aspects you might want to look into that. The issue with implementing a persistent cache is that you have to consider both cold and hot filesystem cache cases: Loading an index file with package names and versions might improve the cold-cache case, but slow things down when the filesystem cache is populated. As has been mentioned, keeping the index updated is the other major issue, especially as it has to be portable and should require little or no configuration/setup for the user (so no extra daemons or special filesystems running permanently in the background). The obvious solution would be to generate the cache after `emerge --sync` (and other sync implementations) and hope that people don't modify their tree and search for the changes in between (that's what all the external tools do). I don't know if there is actually a way to do online updates while still improving performance and not relying on custom system daemons running in the background. As for --searchdesc, one problem is that dbapi.aux_get() can only operate on a single package-version on each call (though it can read multiple metadata variables). So for description searches the control flow is like this (obviously simplified): result = [] # iterate over all packages for package in dbapi.cp_all(): # determine the current version of each package, this is # another performance issue. version = get_current_version(package) # read package description from metadata cache description = dbapi.aux_get(version, [DESCRIPTION])[0] # check if the description matches if matches(description, searchkey): result.append(package) There you see the three bottlenecks: the lack of a pregenerated package list, the version lookup for *each* package and the actual metadata read. I've already talked about the first, so lets look at the other two. The core problem there is that DESCRIPTION (like all standard metadata variables) is version specific, so to access it you need to determine a version to use, even though in almost all cases the description is the same (or very similar) for all versions. So the proper solution would be to make the description a property of the package name instead of the package version, but that's a _huge_ task you're probably not interested in. What _might_ work here is to add support for an optional package-name-description cache that can be generated offline and includes those packages where all versions have the same description, and fall back to the current method if the package is not included in the cache. (Don't think about caching the version lookup, that's system dependent and therefore not suitable for caching). Hope it has become clear that while the actual search algorithm might be simple and not very efficient, the real problem lies in getting the data to operate on. That and the somewhat limited dbapi interface. Disclaimer: The stuff below involves extending and redesigning some core portage APIs. This isn't something you can do on a weekend, only work on this if you want to commit yourself to portage development for a long time. The functions listed above are the bare minimum to perform queries on the package repositories, but they're very low-level. That means that whenever you want to select packages by name, description, license, dependencies or other variables you need quite a bit of custom code, more if you want to combine multiple searches, and much more if you want to do it efficient and flexible. See http://dev.gentoo.org/~genone/scripts/metalib.py and http://dev.gentoo.org/~genone/scripts/metascan for a somewhat flexible, but very inefficient search tool (might not work anymore due to old age). Ideally repository searches could be done without writing any application code using some kind of query language, similar to how SQL works for generic database searches (obviously not that complex). But
Re: [gentoo-portage-dev] search functionality in emerge
On Sun, 23 Nov 2008 21:01:40 -0800 (PST) devsk [EMAIL PROTECTED] wrote: not relying on custom system daemonsrunning in the background. Why is a portage daemon such a bad thing? Or hard to do? I would very much like a daemon running on my system which I can configure to sync the portage tree once a week (or month if I am lazy), give me a summary of hot fixes, security fixes in a nice email, push important announcements and of course, sync caches on detecting changes (which should be trivial with notify daemons all over the place) etc. Why is it such a bad thing? Well, as an opt-in solution it might work (though most of what you described is IMO just stuff for cron, no need to reinvent the wheel). What I was saying is that _relying_ on custom system daemons/filesystems for a _core subsystem_ of portage is the wrong way, simply because it adds a substantial amount of complexity to the whole package management architecture. It's one more thing that can (and will) break, one more layer to take into account for any design decisions, one more component that has to be secured, one more obstacle to overcome when you want to analyze/debug things. And special care must be taken if it requires special kernel support and/or external packages. Do you want to make inotify support mandatory to use portage efficiently? (btw, looks like inotify doesn't really work with NFS mounts, which would already make such a daemon completely useless for people using a NFS-shared repository) And finally, if you look at the use cases, a daemon is simply overkill for most cases, as the vast majority of people only use emerge --sync (or wrappers) and maybe layman to change the tree, usually once per day or less often. Do you really want to push another system daemon on users that isn't of use to them? Its crazy to think that security updates need to be pulled in Linux. That's IMO better be handled via an applet (bug #190397 has some code), or just check for updates after a sync (as syncing is the only way for updates to become available at this time). Maybe a message could be added after sync if there are pending GLSAs, now that the glsa support code is in portage. Marius
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Fri, 14 Nov 2008 11:35:44 +0100 Gilles Dartiguelongue [EMAIL PROTECTED] wrote: Le mercredi 12 novembre 2008 à 18:16 +0100, Peter Alfredsen a écrit : [snip] Mart had already proposed a static-lib USE flag. Donnie just suggested on IRC we turn this use flag into a FEATURES flag. That's problematic. You can't turn off a FEATURES flag for individual packages. See above. yes you can, can't find the related doc (it's not in portage man), but that's what /etc/portage/env/ can do for you. Only for some FEATURES though (depending on where they are implemented).
Re: [gentoo-dev] kerberos USE flag
On Fri, 31 Oct 2008 10:52:59 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Someone remind me again why we have the kerberos USE flag enabled by default? AFAIK it was added so that the default profile provides support for joining a Windows domain (same for the ldap flag). If no one opposes, I say we redact this USE flag asap. Agreed (independent of the current breakage). Marius
Re: [gentoo-dev] [RFC] some global useflags
On Thu, 16 Oct 2008 00:19:27 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 15 Oct 2008 14:47:06 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 05:43:38PM +0100, Ciaran McCreesh wrote: Utterly illegal, needs to die. Why? I don't agree that it needs to be the global useflags, but I don't consider it illegal either. It's illegal. Generated metadata must be constant and can't vary based upon user configuration, because if it does the package manager will show the wrong information at --pretend time. There are also other issues, e.g. it breaks the generation of the @installed package set as the installed slots can't be found in the tree. As portage-2.2 makes increased use of slot atoms internally for vdb handling we got a few bugreports simply due to the cache constraint violation by USE=multislot. Marius
Re: USE=multislot, xDEPEND-syntax in SLOT and Slot dependencies [Was: Re: [gentoo-dev] [RFC] some global useflags]
On Wed, 15 Oct 2008 17:20:32 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: Ignoring Vapier's tirade against ciaranm there, we need the xDEPEND-syntax for SLOTS as the real solution, however that still wouldn't resolve the portion that has CTARGET as part of the SLOT, since metadata generated on the rsyncmaster with a different CTARGET wouldn't match on the clients. Are there significant USE cases for conditionals in SLOT that aren't related to multislot and multiple ABIs? (the whole DEPEND syntax in SLOT doesn't make sense) For allowing multiple ABIs for a package to be installed I'm not convinced that using SLOT is the right solution, this should probably be considered as part of a more general multilib / cross-compile support (there have been different designs for that). And maybe in the (distant) future we can even add real multislot support (same version of a package installed in multiple slots), but that's going to need _major_ vdb and portage API changes first. Marius
Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs
On Tue, 14 Oct 2008 10:59:39 +0200 Jose Luis Rivero [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote: On 02:03 Tue 14 Oct , Jose Luis Rivero wrote: There are some others sceneries but are not so common as the one presented could be. Any decent solution for this case? There are only a few obvious ones, you'll have to pick which one you like best. Most of the other options basically duplicate these in some way or add more work to them for negligible gain: - Backport the ebuild from EAPI=2 to EAPI=0 EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is going to happen when we release new and more feature rich EAPIs), and changes usually come with bugs. The ebuild is committed directly to stable implies bugs in stable, which for me is a no-go. Assuming the ebuild changes between foo-1 and foo-2 are mainly due to the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many cases) you could just reuse the foo-1 ebuild for foo-3. If there are major differences between foo-1 and foo-2 not related to the EAPI change then the maintainer probably didn't want foo-2 to become stable anytime soon, so it's at least questionable if foo-3 should go straight to stable in the first place. And adding a new version directly to stable always comes with a risk, you can't eliminate that completely. It's all about risk assessment, and how much work you're willing to do or time you want to spend to minimize the risk. - Backport the security patch to the EAPI=0 ebuild Which sometimes is going to be impossible, require lot of work, and we fall into the risk of bad backported patches when non trivial backport patches are needed (which turns into buggy patches in the stable branch) And sometimes it's a very viable option when patches are provided by upstream. In the end at least one of the above solutions should work in almost every case. It might sometimes cause a bit more work than a bump that doesn't involve any EAPI changes, but that's life. If you have a real case where both suggested solutions aren't realistic I'd like to hear about it, otherwise I think we're wasting time making up solutions for a non-existant problem Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On Fri, 10 Oct 2008 14:48:19 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: Whatever. Some of you seem to have some quite agressive dislikement to it. In the end it's just a name/tag. I guess I could live with anything, including c3p0. Well, while I dislike x64 I'm more concerned about using different names (amd64 and x64) for the same architecture (same would apply if you had used i386 or ia32 in some cases instead of x86) and was just checking if there was any functional reason for that difference. Marius
Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms
On Thu, 9 Oct 2008 20:11:01 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: amd64-linux x64-openbsd x64-solaris Is there a special reason why you're using x64 instead of amd64 in those cases? (IMO x64 is the most stupid name for the x86_64 architecture) Marius
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On Fri, 10 Oct 2008 00:16:10 + (UTC) Duncan [EMAIL PROTECTED] wrote: Marius Mauch [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 10 Oct 2008 00:05:00 +0200: On Thu, 9 Oct 2008 20:11:01 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: amd64-linux x64-openbsd x64-solaris Is there a special reason why you're using x64 instead of amd64 in those cases? (IMO x64 is the most stupid name for the x86_64 architecture) AFAIK, that's not amd64/x86_64, but rather ia64, aka itanic aka itanium. At least, that's how I'd interpret them since I've seen that abbreviation made before, particularly since there's already amd64 in context. No, x64 is the marketing name Microsoft made up for x86_64 (aka amd64, ia32e and Intel 64), as Windows for x86_64 doesn't sound that sexy, and was later adopted by Sun and others. ia64/Itanium doesn't have any other alias names AFAIK. Marius
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
On Sat, 04 Oct 2008 03:46:41 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote: It would also be important to have versioned sets (depending on a slot, for example). Marius Mauch (genone) suggested a very interesting way to solve this by using a set config file (portage specific) that, as he stated, should work if I got the syntax right from memory [current Portage svn] (something similar to): - sets.conf [slot-4.1] class=dbapi.VariableSet variable=SLOT include=4.1 [kdebase] class=files.StaticFileSet filename=kdebase [kdebase-4.1] class=base.DummyPackageSet extend=kdebase intersect=slot-4.1 Small correction: The example above doesn't actually work as intended, as the VariableSet handler only operates on installed packages, so @kdebase-4.1 would actually contain atoms that are - listed in @kdebase - have SLOT=4.1 - are already installed - sets.conf Being able to take advantage of use deps for packages would be a bonus: kde? ( x11-libs/compizconfig-backend-kconfig x11-wm/compiz[kde] ) Basic use deps are supported (those that don't expand to use conditionals), use conditionals are not, and probably won't be for various reasons. It would be really helpful if we could have a package.mask like structure that allowed users to mask deps from sets (does / could package.mask be used this way?) Well, portage has a set handler for wrapping /etc/portage/package.* files in sets, which in combination with the substraction operator /the remove option in sets.conf can be used for this purpose. Perhaps we should start doing emerge -uDav @world/@installed. What would be the point of that? So this is what I would like to see with sets. Am I crazy? Is it possible to do any of this? Anyone has some other needs? Well, pretty much all what you want is possible with current portage codebase (only available via svn, not released yet), except for use conditionals, and the issue about VariableSet mentioned above, but that's fixable in several ways. Mind that details of the examples above might change over time as that stuff is just a few days old. Using that stuff in the tree however is a completely different issue, as the current sets.conf format will likely never be supported by other package managers than portage (as it's somewhat tied to the portage API). Marius
Re: [gentoo-dev] News item: World file handling changes in Portage-2.2
On Fri, 5 Sep 2008 17:24:57 +0200 Marius Mauch [EMAIL PROTECTED] wrote: - another idea that hasn't been mentioned yet is that we could simply inject @system into world_sets in the portage ebuild when we detect a 2.1-2.2 upgrade (the ebuild already does a few other migrations that way). That would be the least-invasive way to keep the old behavior, but only works for poeple who haven't upgraded to 2.2 yet (not sure if that's a pro or contra) This solution has been implemented now (to be released with 2.2_rc9). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: News item: World file handling changes in Portage-2.2
On Wed, 10 Sep 2008 01:43:45 +0100 Steve Long [EMAIL PROTECTED] wrote: Marius Mauch wrote: Second for the suggestions on how to handle the transition: - treating 'world' and '@world' differently is a no go from my POV. One of the main reasons to implement them as sets was to remove special case code in emerge, so I'm quite opposed to adding new special cases instead. And I'm quite sure that such a separation would cause confusion, and some isues regarding (end-user) documentation. We're talking about one special case in the command-line processing, to support the existing usage that all our users are used to. It adds practically nothing in execution time, simply expanding to @system @world, and means that users who don't want to know about sets, or are not thinking in set terms at the time of using emerge, will get the result they expect. It also means we'd indefinitely have to carry another special case around for legacy reasons (removing it later would be even more painful than doing the switch now). You know, those are the things we want to get rid off, as they really make our life harder in the long run. YOu may consider it trivial in this cse, but these things always look trivial when you're adding them, and you curse about them when you have to modify the code later on. Maybe the best solution is to drop the non-prefixed versions of 'world' and 'system' completely Marius
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
On Sat, 23 Aug 2008 13:39:58 -0700 Zac Medico [EMAIL PROTECTED] wrote: Do the name and definition of this PROPERTIES=live value seem good? Would anybody like to discuss any changes to the name, definition, or both? Not sure if 'live' is really the best choice here, as many things also apply to e.g. automated daily/nightly snapshots/builds that might also be useful to support. Maybe 'unversioned' is more accurate. Marius
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Sun, 24 Aug 2008 14:01:48 -0700 Zac Medico [EMAIL PROTECTED] wrote: Do the name and definition of this PROPERTIES=virtual value seem good? Would anybody like to discuss any changes to the name, definition, or both? If it's only used to indicate that the package doesn't install any files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual' somehow implies that it's only applicable to packages in the 'virtual' category, which isn't the case with the given definition (as you said). Marius
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Tue, 26 Aug 2008 14:20:07 + (UTC) Duncan [EMAIL PROTECTED] wrote: I therefore believe I like just moving them all to a *virtual*/ category better, thus obviating the need for that particular property in the first place. I strongly belive that it's a horrible idea to add special meanings to certain (hardcoded) category names in the package manager. Technically, names (including categories) should only be used as identifiers, not as classifiers. Marius
Re: [gentoo-dev] News item: World file handling changes in Portage-2.2
On Sat, 16 Aug 2008 22:39:41 +0300 Petteri Räty [EMAIL PROTECTED] wrote: As per glep 42 (http://www.gentoo.org/proj/en/glep/glep-0042.html) here is the required email for a new news item. This news item is important because otherwise users will be missing updates to the system set if they continue updating their system with the usual emerge --update --deep world. Unless objections come out the new news item will be committed at the same time as rc8 (rc8 will have an update man portage page describing world_sets). Title: World file handling changes in Portage-2.2 Author: Petteri Räty [EMAIL PROTECTED] Author: Zac Medico [EMAIL PROTECTED] Content-Type: text/plain Posted: 2008-XX-XX Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/portage-2.2_rc8 As of Portage 2.2 the world set does not include the system set any more. If you want emerge --update --deep @world to update the system set too, you need to add @system to the new world_sets file in /var/lib/portage/. For more information on world_sets see man portage. Sorry for not replying earlier, I was without mail access for the last few weeks. First, regarding the news item, I'd suggest that instead of telling users to modify world_sets manually to use `emerge --noreplace @system`. Also there have been more changes that might not be as obvious and only affect people with unusual usage patterns, namely `emerge @world` without using --update or --noreplace will rebuild packages contained in @world (same is true for all other sets). Second for the suggestions on how to handle the transition: - treating 'world' and '@world' differently is a no go from my POV. One of the main reasons to implement them as sets was to remove special case code in emerge, so I'm quite opposed to adding new special cases instead. And I'm quite sure that such a separation would cause confusion, and some isues regarding (end-user) documentation. - adding a new @worldfile set to get the new behavior, and use @world for the old. That one is quite interesting, and should actually be rather simple to implement: rename the existing @world to @worldfile, create a new StaticFileSet @world that just contains @worldfile and @system (stored in /usr/share/portage), change most references in emerge from @world to @worldfile (for technical reasons, the WorldSet class is somewhat special), and add world-candidate=False to the default sets.conf - issuing a warning if 'world' is the only argument would also be a special case, but by far not as invasive as the first suggestion. I've actually considered to mark 'world' and 'system' without the set prefix as deprecated but thought it would be too invasive/annoying at this time. - another idea that hasn't been mentioned yet is that we could simply inject @system into world_sets in the portage ebuild when we detect a 2.1-2.2 upgrade (the ebuild already does a few other migrations that way). That would be the least-invasive way to keep the old behavior, but only works for poeple who haven't upgraded to 2.2 yet (not sure if that's a pro or contra) Though honestly I don't think this issue is as big as some other people make it. People might miss some updates. The same would happen if we remove packages from @system, or people switch profiles (so @system changes). Marius
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On Fri, 01 Aug 2008 19:02:48 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, It might good to add support for a new RESTRICT=live value in ebuilds. By specifying this value, an ebuild would be able to indicate that it uses src_unpack() to download sources from some type of live repository such as cvs, darcs, git, mercurial, or svn. If we go with the RESTRICT solution, I'd rather use RESTRICT=versioned to indicate that a) ebuild version doesn't reflect upstream version (in most cases) b) upstream changes don't result in a new version Marius
Re: [gentoo-portage-dev] [2/4] proto-GLEPS for Tree-signing
On Tue, 29 Jul 2008 20:51:45 +0100 Mike Auty [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, I lost my notes from when I last looked these over several months ago, and only just found them again. I haven't copied this to [EMAIL PROTECTED], so let me know if I should do that. I just had a quick couple of things I was thinking about, and one of them I figured out during my re-read, so it's only really the following... In this Glep (xx+1), in the section discussing the procedure for creating a MetaManifest file, in step 3.3, does that include verification of the manifest's signature if it has one? It would seem odd to ignore the signature if it's wrong (I'm not sure about the case if a signature isn't present). I also don't know how this would then be handled (a complete abort, or ignoring the latest changeset to that ebuild?). I don't think that verification at this stage would be a good idea. The only sane way to respond to a failed check would be to either exclude the whole package from the sync (keeping the state from the last run), leading to various problems (what if it's a critical bugfix/security bump, or breaks a the deptree of many packages?), or not record the Manifest in the Metamanifest, which hasn't any benefits over reyling on the client doing the verification. Marius
Re: [gentoo-dev] metadata.xml USE flag descriptions
On Mon, 28 Jul 2008 12:50:01 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Please make sure you commit any changes to use.local.desc to metadata.xml otherwise you risk the chance of having your changes lost. I'm currently in the process of converting use.local.desc to metadata.xml. After a category is converted, it will be auto-generated EXCLUSIVELY from metadata.xml. This means it will be YOU QA error if you only commit to use.local.desc from here on out. Hmm, maybe we should then disallow commits to use.local.desc on the cvs server completely ... Marius
Re: [gentoo-dev] Re: [RFC] New policy: LDFLAGS should be respected
On Sat, 26 Jul 2008 22:45:29 -0500 Jeremy Olexa [EMAIL PROTECTED] wrote: Arfrever Frehtes Taifersar Arahesis wrote: It will at least allow QA team to fix such bugs where patches are already available. So, if bugs are being fixed why is there a need to fix something that isn't broken with regards to a policy _needed_ to enforce this action? Are bugs being ignored or RESOLVED, WONTFIX? Hypothetically, if there was such a policy and there was 100's of bugs filed with patches (maintainers should handle the patches anyway) Should being the keyword here. Also assumes that all packages are actually maintained. I guess the wording of the original request should have been more like is anyone against QA fixing packages that ignore LDFLAGS?. Marius
Re: [gentoo-portage-dev] portage-2.2-rc3 parallel merges quit being parallel
On Sat, 26 Jul 2008 16:56:20 -0500 Andrew Gaffney [EMAIL PROTECTED] wrote: Duncan wrote: --jobs=10 --keep-going --load-average=15 For a dual-dual-core setup, a load average of 4.0 is fully loaded. Only in ideal cases, when you have long-running processes hammering the cpu and little or no context switches. This isn't the case with builds, the actual compile processes that need cpu time usually terminate very quickly, which increases the load average. I did some benchmarking a while ago with different combinations of -j and -l in MAKEOPTS, using the kernel as testcase, and IIRC the fastest builds were around -l6.0 (on a dual-core system) and high (or unlimited) values for -j (sidenote here: some ebuilds like openoffice parse MAKEOPTS to get parameters for their own build systems, but only recognize/support -j and ignore -l, so one should still be careful with the value for -j). Marius
Re: [gentoo-dev] system set no longer in part of world set
On Mon, 21 Jul 2008 11:02:57 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Marius Mauch wrote: Now that's a big exaggeration. It _might_ be missing from world updates (there are still many cases where it will be included), but that's not the only available operation in portage. Marius We discussed this in #gentoo-portage the other day where I had a machine that was on gcc 4.3.1 (not -r1) and glibc 2.7 and didn't want to upgrade either of those packages to the latest ~arch. I know, but just because it did (not) happen in your case doesn't mean it will be the same for everyone else. Marius
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Sun, 20 Jul 2008 17:41:58 +0400
Peter Volkov [EMAIL PROTECTED] wrote:
В Чтв, 17/07/2008 в 04:51 +0200, Marius Mauch пишет:
At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass
to implement this feature.
Marius, although it's possible to do this things in eclass why is
eclass better? As I see portage's unpack() already has extension -
program to unpack relation. Basically unpack() in ebuild.sh has the
following code:
unpack() {
[snip]
case ${x##*.} in
tar)
tar xof ${srcdir}${x} ${tar_opts} || die $myfail
;;
tgz)
tar xozf ${srcdir}${x} ${tar_opts} || die $myfail
[snip and so on...]
This means that every ebuild which uses 'unpack ${A}' should have in
DEPEND a program which is selected by filename extension of sources.
So as I understood your initial suggestion was to make this happen
automatically. And this is very logical as makes ebuilds cleaner and
more terse. So why did you changed your mind and try to write another
eclass (which then should sit in the tree forever), to create
duplicate unpack function instead of just making step you suggested
initially? Is there any intension to remove unpack logic from package
manager? And if yes, why?
The eclass is provided as a proof-of-concept implementation that can be
used without adding additional infrastructure and implementing and
defining a new EAPI version. PM-based solutions would be nicer
long-term, but are also more tricky to get right (mainly a question
of where to inject the deps). Also the eclass approach has the benefit
that the whole unpack logic can be maintained in one location vs. being
split between multiple places in the package manager and the tree, and
is easier to extend (no need for an EAPI change just to add a new unpack
format).
And as you ask, there have been plans to move quite a bit of
the bash code from portage into the tree (transparently to ebuilds
though) as that's the better place to maintain many helper functions
like do* or new* that are only used by ebuilds/eclasses and not portage.
But those plans have already existed for years (long before EAPI
existed) without anything happening, and they've never been very
specific wrt what exactly could be moved.
Even with a PM-based solution it might be useful, depending on the
actual implementation, to have the unpack() funtion in the tree, for
the reasons outlined in the first paragraph.
Marius
Re: [gentoo-dev] system set no longer in part of world set
On Fri, 18 Jul 2008 10:01:28 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Olivier Crête wrote: On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote: This brings out the fun of circular depends. I don't really know how to address this but a lot of packages are going to have to be updated to contain proper depends. i.e. C based apps will need RDEPEND=virtual/libc. C++ packages will need a stdc++ depend. Adding a dep to libc almost everywhere seems extremely wrong to me. I though we had decided many times that it was a bad idea. Yes. Adding libc everywhere is wrong. However, if you don't have one of the packages listed here [1], your libc won't ever update. Now that's a big exaggeration. It _might_ be missing from world updates (there are still many cases where it will be included), but that's not the only available operation in portage. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] system set no longer in part of world set
On Fri, 18 Jul 2008 16:21:24 +0100 Robert Bridge [EMAIL PROTECTED] wrote: On Fri, 18 Jul 2008 16:30:20 +0200 Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote: IMHO it would be better to teach users to explicitly specify '@system' during updates, e.g. `emerge -uDN @system @world`. Why not just re-instate the implicit dependency of world on system? Because that doesn't actually fix the problem, it just covers it up to some degree (there has never been a guarantee that system is actually satisifed when you install a package). Also the new solution is more flexible as it still allows you to include system in world easily, or update/rebuild system and world separately. And for a full system updates there is a new target available that actually includes all installed packages. Yes, this is going to require some user reeducation, and yes, this will take some time, but it isn't as dramatic as some people make it. The whole implicit-system-dependency thing has never existed, it was always a broken assumption that only didn't blow up badly because a) the system target rarely changes b) most packages only depend on a tiny part of system and c) most users actually do full system updates regulary. As soon as you want to install a package that actually implicitly depends on something in system that isn't already installed the whole thing breaks down. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Thu, 17 Jul 2008 07:00:32 -0500 Joe Peterson [EMAIL PROTECTED] wrote: Marius Mauch wrote: The eclass also contains it's own implementation of unpack (renamed to unpack2) and src_unpack so the logic which tools/packages are used for unpacking can be maintained in a single place instead of being splitted between the package manager and the tree. Marius, these look like nice functions. A couple of questions: 1) Since it requires altering an ebuild to use these features (i.e. no automatic), what is the advantage over just including the dep the usual way? You wouldn't have to maintain the relevant deps, e.g. when you change SRC_URI, when the unpack implementation changes (e.g. adding support for new unpackers) or keeping the conditionals in sync with SRC_URI. 2) The name unpack2 is intended to be temporary, right? ;) I'd guess that after this functionality is integrated into portage, there would be no need for the extra unpack func. But then we'd probably have to keep unpack2 for a long time as an alias. Any way to avoid that? Well, it can't be named unpack to avoid conflicts with the internal portage function. If this functionality would be added on the PM side then there would be no more need for the eclass (you wouldn't want to use both implementations at the same time), and it would be opt-in via a new EAPI, so you'd have to change the ebuilds anyway to benefit from it. So I don't see a need to have a unpack2 alias outside the eclass. 3) Same would go for the needed call for unpack_update_depend, correct? I.e. it would not be needed after portage has this functionality (and at that point, the unpack and dep code would be unified cleanly). So this function would then become a stub, correct? The only thing here is that ebuilds could linger for some time without being cleaned up. See above. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 04:14:18 +0200 Marius Mauch [EMAIL PROTECTED] wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass to implement this feature. It doesn't modify DEPEND by itself, ebuild have to call unpack_update_depend on their own for that, as automatic updates are problematic when you have to take indirect and multiple inheritance of eclasses into account. As automatic updates aren't implemented there is also no need for a RESTRICT setting or similar, and also no requirements on the order of SRC_URI/RESTRICT/inherit. The eclass also contains it's own implementation of unpack (renamed to unpack2) and src_unpack so the logic which tools/packages are used for unpacking can be maintained in a single place instead of being splitted between the package manager and the tree. If someone wants to use it I can add it on the tree (after the normal review process and being better tested), but I'll only be doing it when there is an actual demand for it (no point in adding an eclass that nobody uses). It's still possible to come up with a package-manager-based solution in the future, but for the moment the eclass should help with the immideate problem (though the problem isn't exactly new). Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 19:12:37 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008 04:14:18 +0200 Marius Mauch [EMAIL PROTECTED] wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' Could do it just as an eclass... inherit work-out-my-unpack-deps-for-me In principle, there's nothing that can't be done on the ebuild side here. Right, just I'd expect the parsing of SRC_URI (with conditionals) to be a bit tricky in bash, not something I'm going to work on. An eclass-based solution would have a few benefits though wrt the metadata cache. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Tue, 15 Jul 2008 22:34:33 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 15 Jul 2008 23:23:26 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
Right, just I'd expect the parsing of SRC_URI (with conditionals) to
be a bit tricky in bash, not something I'm going to work on. An
eclass-based solution would have a few benefits though wrt the
metadata cache.
Well... You don't really have to parse it.
for p in $SRC_URI ; do
if [[ ${p} == ( ]] || [[ ${p} == ) ]] || \
[[ ${p%\?} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} $p
elif [[ ${p%.zip} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/unzip
elif [[ ${p%.bz2} != ${p} ]] ; then
UNPACK_DEPENDS=${UNPACK_DEPENDS} app-arch/bzip2
fi
done
Granted, it'll generate invalid output if SRC_URI is invalid (for
example, if SRC_URI has mismatched parens, the output will too), but I
can't think of any situation where breaking DEPEND if SRC_URI is
already broken is a problem.
Interesting idea. Unfortunately our depstring parser doesn't like empty
parentheses (as they are usually problem indicators), so it doesn't
work out.
Marius
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] RFC: auto-detection of unpack dependencies
As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' Benefits: - simplified depstrings for most packages (I assume 90% of the tree) - easier maintenance if dependencies are changing, or additional implementations become supported (this could also be achieved with virtuals though) - potentially more accurate dependencies, as some common errors would be eliminated (e.g. proper treatment of use-conditionals, not adding unpack deps to RDEPEND) - long-term adds the possibility to remove bzip2, gzip and tar from @system Potential problems: - might cause trouble for some packages that use custom code for unpacking, or due to circular deps, this could simply be solved with a new RESTRICT value though. - automagic deps could be confusing to devs/users - not available for existing EAPIs (due to the mentioned problems) - slightly slower dep calculations due to the extra processing - possible match errors So, is this something ebuild maintainers would like in general, or does such a feature cause you nightmares? Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 13 Jul 2008 00:11:18 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Betelgeuse@ dberkholz: with GLEP 55 EAPI X can add the support for scm Betelgeuse@ dberkholz: and older Portage versions work just fine I thought we established that EAPI (no matter how it's defined) only controls ebuild _contents_ ... Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: 0-day bump requests
On Fri, 4 Jul 2008 01:16:09 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: Disclaimer: I'm not really a package maintainer anymore. 1) How do you feel when you receive an early version bump request? I guess like with most people it depends a) If I'm already aware of the new version, or would have noticed it myself very soon I'd get a bit annoyed by them b) How the request is worded. Is it a demand $foo has been released 5 minutes ago, why isn't it in the tree yet?!?), or just a friendly notification, possibly including helpful hints about changes (new deps or configure options for example). c) The nature of the release. If the release is important (e.g. because it contains fixes for security or data corruption issues, or problems affecting many users) then I'm more likely to appreciate an early notification. 2) If you had your way, would you discourage users from filing early version bump requests? Not in general, only if they are worded in some way offensive or don't contain useful information. But that applies to almost any bug report. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] A seemingly bug found when emerging @preserved-rebuild
On Wed, 2 Jul 2008 02:41:14 +0800 Zhang Le [EMAIL PROTECTED] wrote: Is this a bug? or did I miss something here? Thanks for your time! The 'bug' here is that USE=multislot shouldn't exist. People using it should be able to deal with resulting breakages on their own Marius -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] When the version scheme changes
On Sun, 29 Jun 2008 15:52:37 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bo Ørsted Andresen wrote:
On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
PV=${PV/0./}
to that new ebuild. This is the cleanest way to do it and doesn't
require any variable name changes or any other changes to the
ebuild regardless of what it does. Unfortunately it is also
illegal per current PMS as PV is a read-only variable. Right now I
feel that the gain of having PV read-only (catch a few bugs?) is
much lower than the pain (extensive ebuild-dependend changes when
the version scheme changes). Please comment.
I don't really see how making PV not read-only is any easier than
using MY_PV. Did you expect changing PV to magically change P, PVR
and PF too?
If we can agree to have those values writable we could define a
function that will handle resetting all those too.
Not going to happen. These variables are used internally by portage in
various ways, and making their content inconsistent with the version in
the filename is likely to cause subtle bugs and/or weird behavior.
Besides, you've yet to explain the benefit of it, short of avoiding a
simple replace operation in an ebuild, and the given use case isn't all
that common anyway.
Marius
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] When the version scheme changes
On Sun, 29 Jun 2008 18:20:06 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
On Sun, 29 Jun 2008 15:52:37 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bo Ørsted Andresen wrote:
On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
PV=${PV/0./}
to that new ebuild. This is the cleanest way to do it and doesn't
require any variable name changes or any other changes to the
ebuild regardless of what it does. Unfortunately it is also
illegal per current PMS as PV is a read-only variable. Right now
I feel that the gain of having PV read-only (catch a few bugs?)
is much lower than the pain (extensive ebuild-dependend changes
when the version scheme changes). Please comment.
I don't really see how making PV not read-only is any easier than
using MY_PV. Did you expect changing PV to magically change P, PVR
and PF too?
If we can agree to have those values writable we could define a
function that will handle resetting all those too.
Not going to happen. These variables are used internally by portage
in various ways, and making their content inconsistent with the
version in the filename is likely to cause subtle bugs and/or weird
behavior. Besides, you've yet to explain the benefit of it, short
of avoiding a simple replace operation in an ebuild, and the given
use case isn't all that common anyway.
Why can't portage use its own variables and export these with an
initial value but not use them further?
Because there is no need to create even more variables when there is
absolutely no benefit.
Marius
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] License groups
While portage-2.2 has support for license visibility filtering (aka ACCEPT_LICENSE) this currently isn't very usable as we still don't have the necessary default license group and ACCEPT_LICENSE setting in the tree (and even the only existing license group is of questionable use, see bug #228527). So if you care about this feature I'd like to ask you to collect the necessary information to make it usable. This mainly means to create a list of licenses that should be accepted by default. The recommended way to do this is to list the licenses that can not be accepted by default (legally), and trying to classify the rest into more managable groups. See bugs #152593 and #17367 for background information. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Sat, 14 Jun 2008 10:38:18 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Marius Mauch wrote: Ignoring possible semantic issues for the moment, Please point them so I could fix them properly ^^ For example all the ordering issues pointed out by others in this thread. Also the whole 'template' approach is likely going to introduce a number of issues. And as your proposal is lacking a lot of details more problems will come up over time. Which in turn either means that the PM has to internally support the SCMs or support some new phase functions to extract the revision. After some discussions with dev-zero, I think we'll need a new phase, possibly trigged by maint, before I was thinking about adding it to sync. What exactly do you mean with 'maint'? Plus it has similar (unstated) transition issues as GLEP-54, just avoids a new comparison algorithm and the CPV vs. atom issue. Hmm, give me more informations about your concern. Simply how would you actually introduce this stuff without breaking existing setups? Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A few questions to our nominees
On Sat, 14 Jun 2008 12:32:22 + Patrick Lauer [EMAIL PROTECTED] wrote: Portage 2.2 and others support sets, portage 2.2 even supports dynamic sets like the @preserved-rebuild. Shouldn't be that hard to add a live-ebuilds dynamic set. (Comments on the feasibility of my idea from portage people appreciated) Should be simple if there is a definite way to determine if an ebuild is a 'live' eubild or not, wether that's by examining the name/category/version/metadata/external list/moon phase doesn't really matter (well, moon phase might complicate it a bit ;) Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Thu, 12 Jun 2008 11:05:01 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 Just for fun I took some of the ideas about alternative management of the issue and specified the features it makes it worth changing (better management and automated snapshot generation from the live ebuild). http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst I'd like to see some comment on it (I put it in glep form just now so it isn't exactly perfect) Ignoring possible semantic issues for the moment, I'd be against this simply because it would require the PM to be aware of the current revision of the repository and to transform it into a integer value (trivial for SVN, not so trivial for CVS for example). Which in turn either means that the PM has to internally support the SCMs or support some new phase functions to extract the revision. Plus it has similar (unstated) transition issues as GLEP-54, just avoids a new comparison algorithm and the CPV vs. atom issue. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 00:11:32 +0200 Bo Ørsted Andresen [EMAIL PROTECTED] wrote: On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote: Let's try to aim to do an EAPI=2 sometime soonish since Portage now has USE flag depends in version 2.2 which is looming on the horizon. It'd be nice to hit the ground running with supporting these. I know it'll be trivial for the Paludis and pkgcore guys to make this work since they already support USE flag depends. I would like the portage devs to comment upon which of the following features they think could easily be implemented before portage 2.2 goes stable. There's still some time since it hasn't left package.mask yet, so I'd rather they exclude the features that will take too long to implement than anybody else doing that... Well, actually I would rather not add any new features between pre8 and rc1 to not further delay 2.2. And generally I'm also not in favor of adding new features during the rc phase as it's there to eliminate remaining bugs and for refinement of existing features, not to add new unknowns. Already implemented: - Use dependencies, it's not clear to me whether we all agree entirely upon the syntax yet though (bugs #2272 and #174406) Things I believe should be trivial to implement: - Custom output names in SRC_URI, also called arrows (bug #177863) This I'd definitely delay as it probably affects a number of things. - Guarantee trailing slashes (bug #174408) Mostly a matter of finding the relevant spots, the actual work to implement it would be trivial. Could be considered as bugfix. - Limit values in $USE (bug #176467) Also requires little actual work, question is only if this should be enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH. If it should be done for existing EAPIs as well could be considered as bugfix. - doins support for symlinks (bug #179932) If someone implements it it can be included (do you want an EAPI bump for that?) - Enable FEATURES=test by default (bug #184812) Only if 99% of the stable and ~arch tree and all potential system packages build with it (IOW: no) - GLEP 42 - news items Already implemented. Bigger features I'm interested in: - Making do* die on failure by default (without changing their behaviour for previous eapis). Possibly adding either nonfatal or try_do* for cases where this isn't desired. (bug #138792) - More phases - src_prepare, for applying patches and running autotools etc. - src_configure, for running configure scripts (bug #197859) - pkg_pretend (bug #177860 - could also be used to fix bug #75936) - maint_*, it's not clear to me if this has been fleshed out in sufficient detail yet (bug #185567) Unlikely for 2.2. - default_*, allows an ebuild to redefine phases to add more functionality and then call default_$phase. Currently the default phases are lost when redefining the phases. Should be trivial to implement off-hand (just converting the existing defaults to wrappers) - default for src_install (bug #33544) Should also not be terribly difficult, though I'd rather wait until after 2.2 final. - Ranged dependencies (bug #4315) Unlikely for 2.2. Of course I'd like GLEPs 54 and 55 too but since the council still hasn't made a decision about them I'll leave them out.. Well, I already said everything about those during the first discussion round and the relevant council meeting. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] merging two packages - upgrade path?
On Thu, 5 Jun 2008 13:44:06 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008, Matthias Schwarzott wrote: With #1 the user will get a message about the blockers immediately. With #2 his emerge (maybe of many packages) will needlessly die when it reaches your package. With #1 user will get no message, as neither the user nor the package manager know of the merged package that should be emerged. So nothing depends on it that would pull in the new package? Now I see what your problem is. ;-) Isn't it possible to package.move -server or -client to the new package? Assuming you're talking about global updates commands: Don't use it for this kind of use case. The move command just renames a package in vdb, and using it for anything that goes beyond a simple relocation in the tree _will_ result in problems later on (we've been there already). Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
On Thu, 05 Jun 2008 15:42:24 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: All, Here's a GLEP for the addition of USE flag descriptions to package metadata. It does not address any future ideas that others may have had or suggested. It merely gives developers the necessary tools to document their USE flag usage it better detail on a per package basis. An clearly motivation explanation that I didn't add, which I'm going to add once I send this is the fact that as per the QA Project, use.local.desc can not contain a USE flag that already appears globally in use.desc. This would allow a description for that USE flag to be contained in the metadata. http://www.gentoo.org/proj/en/glep/glep-0056.html I encourage any and all _technical_ feedback. Doesn't include any statement about compability with existing tools or how it's related to use.local.desc (replacement, extension, ...) Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
On Thu, 05 Jun 2008 17:01:00 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Marius Mauch wrote: On Thu, 05 Jun 2008 15:42:24 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: All, Here's a GLEP for the addition of USE flag descriptions to package metadata. It does not address any future ideas that others may have had or suggested. It merely gives developers the necessary tools to document their USE flag usage it better detail on a per package basis. An clearly motivation explanation that I didn't add, which I'm going to add once I send this is the fact that as per the QA Project, use.local.desc can not contain a USE flag that already appears globally in use.desc. This would allow a description for that USE flag to be contained in the metadata. http://www.gentoo.org/proj/en/glep/glep-0056.html I encourage any and all _technical_ feedback. Doesn't include any statement about compability with existing tools or how it's related to use.local.desc (replacement, extension, ...) Marius It purposefully does not. XML is an extensible language that allows for this type of expandability. Current tools should be able to validate that adding these tags are valid if they appear in the DTD. However, if those tools do not handle those tags they should not do anything with them, hence the nature of XML. I was more talking about tools that process use flag information (equery, euse, ufed, ...). The replacement of use.local.desc would necessitate a change to any and all tools which use that file and require them to support the new XML data. This of course introduces a chicken/egg issue. I have mentioned to infra the possibility of having a pre-rsync process that condensed all metadata.xml's into a use.local.desc that would be part of rsync data but not part of CVS. This could be written as a CVS hook to see when a metadata.xml was touched and run the utility appropriately. But again, this is outside the scope of this GLEP, whose purpose merely is to provide a way to document this. I disagree. At the very least state that the GLEP does not replace use.local.desc if that's the intention, and which location is supposed to take priority if a flag is defined in both. Otherwise different tools will use different rules and generating inconsistent results. And there are many tools affected by this ... Marius PS: I like the general idea, but as long as compability issues are completely ignored by the GLEP I have to oppose it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 04:26:39 -0700 Alec Warner [EMAIL PROTECTED] wrote: Just to jump in quickly; this thread is about adding --as-needed to the default CFLAGS. To get this accomplished you need to: A. Convince the portage developers to put it in make.conf/make.defaults. Wrong. We don't control make.conf (the user does) or make.defaults (profile maintainers do). We only control make.conf.example (which these days only serves as documentation) and make.globals (which isn't the right place for any arch-specific stuff, and CFLAGS are arch-specific by definition). Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 00:47:44 +0300 Mart Raudsepp [EMAIL PROTECTED] wrote: Portage developers - is there anything we should do to get --as-needed to make.conf.example and other places, beyond fixing the known bugs on the appropriate bug tracker? make.conf.example is no big deal, that's just documentation, though personally I'd prefer to remove the toolchain (CHOST, *FLAGS) stuff from there so we don't have to maintain all the arch-specific diffs. If you want to really enable it by default you'll have to persuade the profile maintainers to add it into the appropriate make.defaults. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?
On Thu, 29 May 2008 09:28:16 +0100 Mike Auty [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: | The purpose of this is to keep the system operational after library | upgrades until all affected packages could be rebuilt and to | simplify the process, not to avoid the rebuilds. I couldn't find it mentioned in your email, but if portage is effectively doing reference counts, what happens when its reference count gets to 0? Once no ebuilds rely on the old library is it removed automatically, or do the you need to rebuild these message just go away? They are removed automatically. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Thu, 29 May 2008 11:02:55 +0200 [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: Marius Mauch [EMAIL PROTECTED] writes: As much as we want preserve-libs to be an all-curing magic, it's not. When you need to replace a library you need to do so _for all its users at once_, if you allow it to be gradually you're opening the hellgate of symbol collision. That's what `emerge @preserved-rebuild` does, or do you mean something different? My solution would be to disallow _building_ anything that is or depends directly or indirectly on a package on the set until it is removed, or at the request of merging mickeymouse, depending on bar, re-emerging libfoo first, and bar if the user is not using --as-needed (checking the NEEDED lines). Well, with preserve-libs the situation is this (using your example): - user upgrades expat, portage keeps libexpat.so.0 around (some packages might now be linked against both versions if the session included other packages as well) - emerge tells the user to rebuild all affected packages (affected = contains libexpat.so.0 in NEEDED, so includes both libfoo and bar) by using `emerge @preserved-rebuild` (in the future this could also be done automatically, but that won't be before 2.2 final) - when all affected packages have been rebuilt (so their NEEDED entries don't contain libexpat.so.0 anymore) libexpat.so.0 is automatically removed So, if I understand you correctly (probably not), you want portage to prevent the user from building any packages depending on any affected package before the last step is completed? With all due respect to everybody, the right course of action here has to be selected by people who knows how the runtime linker works, symbol collision and all the rest, as that's what's at stake here. Whoever that is is welcome to voice his opinion here, that's the point of this thread after all. Marius -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] RFC: Should preserve-libs be enabled by default?
As portage-2.2 is about to be unmasked into ~arch soon (there is one weird bug to solve before) it's time to ask for some input on one of the important new features, FEATURES=preserve-libs. (if you're already familiar with it you can skip this paragraph) Simply said, when this feature is enabled portage keeps track of all installed libraries and binaries linked against them, and if a package upgrade would remove a library that's still in use portage will keep the library around, owned by the new version and also registered in a separate file. There is also an internal package set that can be used to rebuild all packages linked against libraries preserved in this way, and the user is notified after each emerge operation that he should do that (the example is from an expat downgrade in case you wonder about the versions): !!! existing preserved libs: package: dev-libs/expat-1.95.8 * - /usr/lib64/libexpat.so.1 * - /usr/lib64/libexpat.so.1.5.2 Use emerge @preserved-rebuild to rebuild packages using these libraries The purpose of this is to keep the system operational after library upgrades until all affected packages could be rebuilt and to simplify the process, not to avoid the rebuilds. Now the question is if this behavior should be enabled by default? In the existing prereleases it has been enabled to get some real-world testing, and it's been quite effective, though there are still a few issues to be worked out (e.g. if libraries are moved between packages). And no doubt a few more bugs will turn up over time. Also it is not going to be a perfect solution against all runtime link errors, but if enabled it should eliminate the need for revdep-rebuild in most cases. One concern raised by some people is that it might cause old libraries with security issues to stay on the system for eternity even though the package was upgraded, and eventually be preferred by new builds. I can't rule this out completely but thinks it's very unlikely, as preserved libraries are specially tracked and the user is notified about their existance after every emerge operation (similar to glep42 news). And new builds shouldn't find them as the unversioned .so symlinks ar going to point to the current versions. So personally I'm not too worried about this concern becoming reality, but I can understand if others are. So, do you think it should be enabled by default? Marius PS: Obviously, if you haven't tested portage-2.2 yet, now would be a good time. -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: About herds and their non-existant use
On Thu, 22 May 2008 08:05:07 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: While I think the herds concecpt is somewhat useless, I'd rather like to see something like this instead: maintainer teamfoobar/team /maintainer This makes it clear that it is a team instead of a person (where name would have been used) And the herds.xml isn't completely useless, but I'd rather name it teams.xml and list the teams there. This way we can validated the team mentioned in team.../team against the list of available teams and make sure the complete thing is valid (can be done in the current metadata.dtd or in a future metadata.xsd). (If we're gonna re-use the email.../email element for the herd-alias, we can never validate it. And I'm personally for the: if something can be automatically validated, it should be) Hmm, in that case maybe it's be possible to use a similar system for devs, e.g. maintainer devgenone/dev /maintainer and only use the email element for non-dev maintainers and upstream contacts. Anyway, as long as we use the same tag to list both individual and group maintainers it would be an improvement IMO. This would have a number of benefits: - you no longer have to look at herds.xml to determine the actual maintainers of a given package (as herd-name and associated mail alias don't always match) I don't consider this much of a problem. You just have to know xsl/xpath to cope with this as generating the list of mail-aliases to assign this bug to is a simple xsl-transformation... When we use XML we can also use the right tools to handle them, can't we? My point is that it's an unneccessary extra step Sometimes you only have the raw XML file. Anyway, that's maybe more of a policy problem, we just need to enforce 'name == mail alias' (or would that be such a horrible requirement?) - it would simplify bug assignment rules, as the current case where a package has both a herd and a maintainer tag in metadata.xml no longer exists It doesn't. You can still have more than one maintainer in there. We'd have to introduce an attribute to mark the primary maintainer. Relying on the order of maintainer elements doesn't work because ...? (Assign to first listed maintainer, CC others) - only have one location where members of a given team are listed, currently it's possible and quite likely that herds.xml and the mail alias files get out of sync Well, we need one location where the name of the team is mapped to the actual mail-alias. But I don't get what you're trying to say... Why do you need to separate the name from the alias? Sure, sometimes there are technical reasons why you can't use your preferred name as mail alias (when it matches a system account), but then you can just adjust your name a bit (e.g. adding some suffix). Don't know if you're aware of this, but the separation of herd names and aliases of the herd maintainers has always been something that bug-wranglers complained about. But my main issue is that currently we have multiple unconnected locations where teams are defined, some more and some less important: - herds.xml - project pages - mail aliases - cvs access groups - role definitions in ldap/roll-call So when someone wants to change his roles there are a lot of places to care about, and it's likely that one or more are forgotten and things get out of sync, so you have different views of who actually belongs to a group depending on what source you use. Don't know if it has improved in the last years, but it used to happen quite often that herds.xml was completely out of sync with reality simply because it didn't really affect anything (now that jeeves is using it it's probably become a bit better). Ideally we could list that information in just one authorative location, but that's not feasable for technical reasons, but if we can eliminate one source (or auto-generate it from another source) the problem is already reduced quite a bit. And herds.xml is IMO the most likely candidates for that, but there are of course also other ways to improve the situation. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: About herds and their non-existant use
On Fri, 23 May 2008 14:07:41 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: On Fri, May 23, 2008 at 10:39 AM, Tiziano Müller [EMAIL PROTECTED] wrote: Marijn Schouten (hkBst) wrote: While we're changing things around, perhaps we can then also standardize the mail alias to [EMAIL PROTECTED] What Marius is saying though is that there are two files that handle people and their herds. One XML for saying who is in a herd and one for each herd mail alias on woodpecker with a list of developer email prefixes. Which could be generated out of the XML file, right? It could, but it would be nice to preserve a method for allowing lurkers on aliases. I'm sure something like this should be possible: ### AUTOGENERATED PART, DO NOT EDIT ### ... ### AUTOGENERATED END ### ### Add additional aliases here: ... When you want to generate mail aliases from an XML file I'm quite sure you could list lurkers in the XML file by tagging them somehow (attribute or different element name). The main thing is to have one authorative location. Marius -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-project] About herds and their non-existant use
Moving the discussion to -dev per leios request. On Wed, 21 May 2008 23:42:19 +0200 Marius Mauch [EMAIL PROTECTED] wrote: As this topic jus came up in #-dev, and most people there seemed to agree with me I thought it might be worth to bring this topic up again. The topic is that I think that the whole 'herd' concept we're using is a huge mess and should be removed. Now before eveyone starts screaming, lets look at what this concept actually is, as many people are quite confused by it: 1) a herd is a group of packages (not a group of people) 2) the herds.xml file is used to assign people and mail aliases as maintainers of a given herd. Unfortuntely the syntax there give the impression that those people/mail aliases actually form the herd 3) the herd tag in metadata.xml is used to assign a package to a certain group. 4) the maintainer tag in metadata.xml can be used to assign individual maintainers for a package in addition to/instead of the herd maintainers 5) the combination of 2), 3) and 4) is used to determine the maintainers of a given package Now most people will be familiar with 5) to some degree, and that is actually the only valid use case for the herd concept that I'm aware of. Or has anyone some use case where you'd like to know what herd a package belongs to, but don't care about by whom that herd is maintained? If we can agree that this is the only real use case for the herd concept, then I think the concept is quite useless as it's just a redundant layer of indirection. You could just list mail aliases directly as maintainers, without having to consult herds.xml first. This would have a number of benefits: - you no longer have to look at herds.xml to determine the actual maintainers of a given package (as herd-name and associated mail alias don't always match) - it would simplify bug assignment rules, as the current case where a package has both a herd and a maintainer tag in metadata.xml no longer exists - eliminate confusion about what a herd actually is - only have one location where members of a given team are listed, currently it's possible and quite likely that herds.xml and the mail alias files get out of sync - as others said in #-dev: it makes sense ;) Now there of course are a few things to consider: - obviously, some tools, docs and processes would have to be updated, but that's always the case with changes - someone said that it might no longer be obvious if a package is maintained by an individual or a group of people. But is that really necessary? And it's not even obvious now, as some herds are maintained by a single person. - when I brought this up several months ago it was mentioned that sometimes people want to be on the mail alias of a herd, but don't want to be listed as members (and therefore be responsible). But that can likely be just implemented by some kind of blacklist in the relevant tools instead of using this whole indirection layer all the time. So, what do you think? Is there some benefit in keeping this concept, or can we live without it and make life simpler for everyone? Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Repoman subversion support
On Mon, 12 May 2008 20:01:34 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: After a short discussion on #-portage, here a feature patch from the prefix branch, diffed to the trunk, irrelevant hunks removed. Antarus once was working on factoring out the vcs bits of repoman into pym/repoman/utilities.py, but he never finished it. I'm willing to give that some more time, provided it'll end up in the trunk. Sofar, here's the svn patch that we tested extensively in Prefix ;) I still believe that it has a significant value for non-Prefix users (overlays...), even though the code doesn't deserve any price for its beauty. I'd say it fits nicely with large chunks of Portage :p Merged in r10325 with some minor changes (removed the 'svn update' bit until someone remembers why exactly it's there, skip the commit optimization for svn regarding Manifest regeneration, unify isVcs and vcs variables) Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Moving some packages around
On Mon, 12 May 2008 02:58:55 +0200 [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: - bison and flex should get out of the system package set, what clearer than moving them out of sys-*? system and the sys-* categories don't have much of a relationsship, so that's no argument IMO. Yes these are a lot of moves, sincerely I think sys-* categories are a bit bloated as they are, and I suppose we should start moving the things around rather than waiting forever ad ever.. I don't consider that to be a valid reason when looking at the following numbers: $ ls -1 /srv/portage/porttree/dev-util/ |wc -l 265 $ ls -1 /srv/portage/porttree/sys-devel/ |wc -l 41 ~40 packages isn't much for any category, if you really want to relocate packages you could just as well eliminate the entire category. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] escaping variables in sed expressions
On Tue, 15 Apr 2008 16:17:54 +0200 Frank Gruellich [EMAIL PROTECTED] wrote: * Santiago M. Mola [EMAIL PROTECTED] 15. Apr 08: On Tue, Apr 15, 2008 at 1:14 PM, Marijn Schouten (hkBst) Currently is use ':' as sed delimiter when paths are involved. I'd also like to hear from you about proper delimiters if you think ':' is not safe enough. AFAIK, the only corner case which would make this fail would be Windows paths (C:/gentoo-prefix). Even though it's probably stupid to use it, but ':' is a valid character within a path. I've no solution for this problem, however. Valid maybe (but then pretty much every character is valid), but colon is used as path delimiter in many other contexts (e.g. $PATH) so it's rather unlikely to be used. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] BNF for DEPEND in EAPI0 and EAPI1
On Sun, 13 Apr 2008 20:04:41 +0200 Björn Michaelsen [EMAIL PROTECTED] wrote: Hi there, I worked through the current PMS and tried to formalize the grammar for DEPEND a little better. Maybe someone could have a look at it and check it for correctness. It could even become part of the gentoo development docs or be an appendix to the PMS. The other grammars (SRC_URI etc.) should be fairly easy. Any comments? Offhand the 'package name' part is wrong/incomplete, pretty sure even PMS says that they can't start/end with underscores or dashes (it's a real PITA to get it right). Haven't really read the non-terminals section as it's hard to read in this form, using EBNF or some markup language might help with that. Marius -- gentoo-portage-dev@lists.gentoo.org mailing list
[gentoo-dev] changes to staffing-needs page and project pages
Since a few weeks ago project pages can contain a new recruitment section to list open positions within the project that require fresh blood (thanks to neysx for implementing this). Historically those were only listed centrally http://www.gentoo.org/proj/en/devrel/staffing-needs/index.xml, which had a number of problems (limited visibility, unclear responsibility) But as a central page also has advantages that page has been updated to collect the recruitment sections from project pages and list them all in one place (again thanks to neysx for the implementation). I hope that this new feature will help us to better communicate where users can help the project and improve our recruitment process. Marius PS: people with existing entries on the old page have been notified a few weeks ago with the offer to migrate their entries, and only when people replied have their entries been migrated. -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: querying whether pkg is installed with version X or upwards (atom syntax) (re-post)
On Wed, 26 Mar 2008 12:07:13 +0200 Amit Dor-Shifer [EMAIL PROTECTED] wrote: reposting, hoping for a reply this time. Thanks, Amit Amit Dor-Shifer wrote: emerge features syntax for installing a package according to certain bounds. This is referred to in the manpage as atom specification. I'm wondering whether equery has the same feature for querying. E.G: I'd like to be able to ask: equery l '=app-misc/my-pkg-1.1' I'd expect the listing to be empty when my-pkg is not installed, or is installed by of version less than 1.1. Well, most equery subcommands support the same atom syntax, just 'list' and 'size' apparently don't implement it, as those support regular expressions instead. Marius -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Remaining PMS todo list etc
On Wed, 19 Mar 2008 18:32:41 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: There's an updated, pre-built copy of current PMS at: http://dev.gentoo.org/~spb/pms.pdf Thanks for keeping up with this. * 174335: Some ebuild use FEATURES. Can we get them to stop doing that, or do we have to force package managers to emulate it? We seriously need a PM-independent way of saying run the testsuite, run the testsuite with user privledges, and run the testsuite with root privledges if you can, otherwise forget it. Also required is the ability to make test failures non-fatal on a per-package basis, though this probably has nothing to do with the PMS. How about just checking EUID == 0 in src_test and skip the tests (with a ewarn message) if it doesn't match your needs? Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: New build types
On Thu, 20 Mar 2008 03:59:01 + Steve Long [EMAIL PROTECTED] wrote: Rémi Cardona wrote: What would be the point of such a change? What problem are you trying to solve or to improve? Secondly efficiency; in the case of a pbuild it could be run from within the PM; for something like a jbuild it would use the native tools and existing libraries like ANT. For hbuild it would tie into Cabal. While these may be used already, we go from PM - BASH - LangX. I'm just saying give the _option_ to leave out the BASH bit when you have mature tools in langX. Generally those build tools are designed to be invoked from the shell, not from within their implementation language. Of course you can invoke use a distutils setup.py script from within a python interpreter, but that's not how it's designed to be used and will probably end up being more complicated to handle than invoking it from the shell. Maybe it's 1% or 2% faster, but that's not worth the additional complexity. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask
On Sat, 15 Mar 2008 01:34:24 -0700 Alec Warner [EMAIL PROTECTED] wrote: On 3/14/08, Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 14 March 2008, Alec Warner wrote: On 3/14/08, Mike Frysinger [EMAIL PROTECTED] wrote: i think the real solution here is allowing masking in a package You want to add a metadata key and cache it you mean? i dont care terribly much about the logistics, just the results. as long as an ebuild can declare itself masked, it sounds good to me. this doesnt preclude the other ideas as there are often times where you want to have 1 global package mask piece (like large package set bumps ... so X or KDE or GNOME or ...). -mike [-gentoo-qa, +gentoo-portage-dev] Original thread was splitting up package.mask entries. Genone notes the code to do this already is basically in already (we just don't invoke it for $PORTDIR/profiles afaik). Genone, do we use existing code for package.mask (ie if we switch from a file to a dir will it break existing versions? I am unsure if we used the directory code for $PORTDIR/profiles/* The handling code for all package.mask files is identical, in particular they all support recursion (just search for package.mask in portage/__init__.py). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On Wed, 5 Mar 2008 22:41:58 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: Hi, If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. If it's not too late for this month's meeting, I'd like to discuss the possibility of including a new post in our developer base - the package maintainer. a) The requirements to become a package maintainer for Gentoo may be lesser than that of the full-fledged developer. Please elaborate on how a full.fledged developer would differ from a package maintainer technically. What requirements and/or priviledges do you think could be reduced? Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Proposal for (next year's probably) SoC
On Wed, 05 Mar 2008 22:07:37 +0100 [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: The tasks are minor tasks that don't require a lot of time at hand, but gives a good way to judge if the person is in for the experience or the money, and might be able to cut the deal even for Gentoo devs if that is really wanted. How to implement it for Gentoo? Well I think we have the tool already: Bugzilla. We just need to add a keyword SOC_QUALIFICATION_TASK; when a developer think of a working qualification task, he can add the keyword and CC the soc team or something like that. While the concept itself is a good one, I think that such qualification tasks have to be related to the proposed project to be of real use. With a single codebase and a single implementation language like ffmpeg a single list of tests can work, but Gentoo has many aspects that require completely different skills. For us a generic list of tasks you may help in testing the motivation, but it hardly helps to assess the technical skills of a student to complete e.g. a webapp project if he fixes some ebuilds or writes a patch for a random package. I think we should just require students to list some references related to their project in their application and have the relevant mentors check those. If a student can't find some references on his own he can the soc team/mentors/devs for something. In fact I think what is needed most is improved communications instead of random tests. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] please explain use of hooks
On Sun, 2 Mar 2008 11:18:39 +0100 Jonas Bernoulli [EMAIL PROTECTED] wrote: And if not the handbook this should really go into the portage manpage. bashrc If needed, this file can be used to set up a special environment for ebuilds, different from the standard root environment. The syntax is the same as for any other bash script. + One thing you can do here is define phase hooks. + A phase hook function name begins with a pre_ or post_ prefix to indicate that it will be called before or after one of the ebuild phases. The prefix is followed by the name of the ebuild function that the hook will be associated with. + For example, a hook named pre_src_compile will be called before src_compile, and a hook named post_src_compile will be called after src_compile. Care to write a patch? (nobody likes to edit manpages) postsync.d should also be documented there. No, as it isn't used by portage itself. All in all now that I have looked at the documentation installed with portage I think it is obsolete. Not in the sense that it is outdated but everything in it is documented elsewhere already or should be moved there. Well, it's horribly incomplete and a work in progress. Eventually it will replace the manpages (in the sense that manpages will be generated from the same source). And authorative documentation (which isn't exactly the same as a specification) should be kept with the implementation, and that's not the case with the dev handbook/manual. If some developers an the list agree with me and welcome me to do so then I could file a bug(s) for those changes. No. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Google SOC 2008
On Tue, 26 Feb 2008 10:32:45 -0800 joshua jackson [EMAIL PROTECTED] wrote: All, Google is once again doing the summer of code for students. I'm helping organize it this year and am putting out a call for some elements to help. 1) We need idea's for things to do. Diego has already submitted some via his blog which have been taken into consideration. 2) We need mentors, so far confirmed I have: Diego and Saleem Something nice would be to reimplement revdep-rebuild as a package set for portage-2.2 (the ground work for that is already done, but most of the processing logic from revdep-rebuild is still missing). Unlike most other portage-related ideas this one doesn't require a huge understanding of portage internals, and I'd be willing to mentor applicants for this. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Keyword amd64 - x86_64
On Wed, 20 Feb 2008 19:40:23 +0100 Fabian Groffen [EMAIL PROTECTED] wrote: On 20-02-2008 19:23:26 +0100, Marius Mauch wrote: On Wed, 20 Feb 2008 12:59:11 -0500 William L. Thomson Jr. [EMAIL PROTECTED] wrote: Please excuse my ignorance if this is a naive comment or has been brought up before. With all the non amd processors now with 64bit support. amd64 as a keyword seems a bit odd and off maybe. What's the possibility of switching amd64 to x86_64? Unless the work to do that is greater than the value of the change. As the benefit is close to nothing IMO the required work is definitely greater by several orders of magnitude. Well, that depends a bit. We basically introduced x64 a shorthand, and changed some keywords in prefix, of which I just finished the transition. It's basically just setting the new keyword in the profiles, and then gradually changing the keywords, e.g. on a repoman commit. That's sort of how I did it. You don't need any Portage support, IMHO. - sorry, but comparing prefix with its limited and (I assume) technically skilled userbase that is used to change to the main tree where people sometimes don't update their system for years is like comparing apples and oranges - you forgot the necessary updates to documentation and renaming of other amd64 related stuff, only changing the keyword would make things worse IMO - what I wanted to say is that any amount of work required to realize this is greater than the benefit - x64 is IMO the worst name for the architecture (originally a MS marketing term later adopted by Sun, looks too similar to x86, name doesn't make any sense really if you compare it to x86) Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Keyword amd64 - x86_64
On Wed, 20 Feb 2008 12:59:11 -0500 William L. Thomson Jr. [EMAIL PROTECTED] wrote: Please excuse my ignorance if this is a naive comment or has been brought up before. With all the non amd processors now with 64bit support. amd64 as a keyword seems a bit odd and off maybe. What's the possibility of switching amd64 to x86_64? Unless the work to do that is greater than the value of the change. As the benefit is close to nothing IMO the required work is definitely greater by several orders of magnitude. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Wed, 13 Feb 2008 01:44:22 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
What do you think about adding support to base.eclass for running
eautoreconf?
so instead of
src_unpack() {
unpack ${A}
cd ${A}
eautoreconf
}
would just add
EAUTORECONF=yes
inherit base
How many packages do you think could directly benefit from this?
Marius
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] new portage categories
On Thu, 7 Feb 2008 12:56:43 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: On 15:12 Wed 06 Feb , Alec Warner wrote: On 2/4/08, Jonas Bernoulli [EMAIL PROTECTED] wrote: On 2/4/08, Donnie Berkholz [EMAIL PROTECTED] wrote: On 20:11 Mon 04 Feb , Jonas Bernoulli wrote: Thinking about it again I would say tags and categories just fulfill different purposes. Tags can not replace categories but might be a useful extension to categories for the tasks I described, not more not less. They are not better or worse, just different:) Why don't you think they can replace categories? Quick answer: Because there are packages with the same name in different categories. How would tags deal with that? Techincally you could enforce UNIQUE(pkg,[tags]), I agree thats a poor constraint though ;) I would probably print the ambiguous package name, with info on each package, and a list of tags unique to each that could be used to specify which one you want. Perhaps a numbered list too. That only works for the user interface, not so good for depend strings, config files and pretty much everything else. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Changes to some profiles
On Sat, 02 Feb 2008 09:50:21 +0100
Rémi Cardona [EMAIL PROTECTED] wrote:
Vlastimil Babka a écrit :
How about just some elog If you use make install, emerge
--noreplace debianutils in the kernel's postinst or something.
Bellow is my contribution to this thread :)
Cheers,
Rémi
--- kernel-2.eclass 2007-12-17 17:06:02.0 +0100
+++ kernel-2.eclass 2008-02-02 09:48:25.0 +0100
@@ -659,6 +659,11 @@ postinst_sources() {
ewarn For specific information on why this kernel
is unsupported, please read:
ewarn
http://www.gentoo.org/proj/en/security/kernel.xml; fi
+
+ # display debianutils message
+ echo
+ einfo If you use \make install\ to install your kernel
to /boot,
+ einfo you will need to emerge \sys-apps/debianutils\
}
postinst_headers() {
s/einfo/elog/ and people might even read it ;)
Marius
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Move SCMs to their own category?
On Fri, 1 Feb 2008 17:57:39 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 1 Feb 2008 12:52:16 -0500 (EST) Caleb Tennis [EMAIL PROTECTED] wrote: It seems like all source control/revision control programs live in dev-util, but they might be better served in something like dev-scm or something like that. I'm thinking things like darcs, git, cvs, svn, mercurial, bzr. Then the slew of packages that depend on them: gitosis, bzrtools. Any objections to this potential move, or comments on a better category name? You might want to ask Seemant (?) why he didn't do the move several years back. There were plans to do it, but it never happened for some reason -- not sure whether it was just a time issue or whether there was something in particular that made it impossible. IIRC it was because you argued that cvs didn't qualify as a VCS (as the proposed category name back then was app-vcs) Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] debianutils: system worthy ?
On Mon, 28 Jan 2008 21:43:38 +0100 Matthias B. [EMAIL PROTECTED] wrote: What's wrong with making it an optional dependency? Something like a useflag Because if this would be done consistently we'd end up with several thousand use flags long term, not really what I'd call managable. Unfortunately use flags aren't the answer to everything. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] How to force homedir on enewuser
On Fri, 18 Jan 2008 03:46:58 +0100 Hanno Böck [EMAIL PROTECTED] wrote: What is the correct way to handle this? I'd suggest that enewuser might get some force-parameter that tells it to delete and recreate the user if it already exists. Thoughts? Tell the user to do it manually in pkg_setup/postinst. This is something that IMO shouldn't be done by the ebuild/package manager for two reasons: - extreme cornercase, or how often does this come up? - the system might rely on the current settings in unexpected ways Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Seeking questions for a user survey
On Wed, 16 Jan 2008 15:09:20 +0100 Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote: 2008-01-15 15:05 Marius Mauch [EMAIL PROTECTED] napisał(a): - what feature would you like most to be implemented in portage? (parallel builds, localization, revdep-rebuild integration, overlay sync support, gpg verification support, support for non-ebuild repositories, better query tools, interactive user interface) Other features: USE flag dependencies, repository dependencies. I've not listed those (and a few others where we know that they are critical) on purpose. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Seeking questions for a user survey
On Mon, 14 Jan 2008 04:33:48 -0800 Robin H. Johnson [EMAIL PROTECTED] wrote: Ok, so per the one discussion in #-dev this evening, I'm looking for questions to put on a new user survey. For style of questions, multiple choice (both pick-one and pick-many) or simple integers would be best. However some freeform questions are probably going to end up in there anyway. 'Prefer not to answer' and 'I don't know' should be available in most questions. I don't have the original questions on hand right now (but i'm trying to get them), so used some classical census questions. Some of the ones I threw in are just what came to mind, I'd love to hear more questions and more sections. In the style of census, maybe offering a short form and a long form questionnaire would be useful too? Basic demographics - a bunch of this should probably be optional but recommended - Gender (M, F, and the various other forms here) - Year of birth - # of children?? - How many years have you been using computers? Sociocultural information (again, optional stuff): - Location (country, and free-form city) - Level of education? - Job? (type coding this one is hard, and I'd prefer not to have it) - Income level Such questions usually are a reason to not complete a survey for me, and I don't see how they are relevant to us (except for maybe location). - Do you share your portage tree between systems - Do you share your distfiles between systems - Do you share your binpkgs between systems Those should all be multiple choice or at least be more explicit due to multiple meanings of share (and in case of binpkgs a I don't use binpkgs option should be present as well in some way) Portage-related questions: (portage team, maybe you can help here?) (just brainstorming here) - what feature would you like most to be implemented in portage? (parallel builds, localization, revdep-rebuild integration, overlay sync support, gpg verification support, support for non-ebuild repositories, better query tools, interactive user interface) - do you think that portage has improved significantly over the last 12 months? - how happy are you with portage in general (scale 1-10)? - how happy are you with portage documentation (manpages, official online docs, ...)? - do you use pkgcore/paludis in addition/in place of portage on Gentoo (yes/no/don't know what pkgcore/paludis is)? - would you be in favor of an automated feedback system to report successful/failed package installations for statistical purposes (yes/opt-out/opt-in/no)? - how important is backward compability in the user interface for you (e.g. names of commandline options, output format)? Mind that the survey shouldn't contain too many questions, or many people won't complete it IMHO. I guess 10-30 questions might be the sweet spot, if we have much more we should run multiple surveys for specific topics spread over time. Also can we take measures that such general surveys are repeated at regular intervals (once per year/6 months), as a single survey is a nice snapshot, but the really interesting thing are the trends evolving over time. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] Reducing the size of the system package set
On Tue, 08 Jan 2008 00:42:57 +0100 [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: I already ranted about the fact that the dependency tree of our ebuilds is vastly incomplete, as many lack dependency on zlib; trying to get this fixed was impossible, as Donnie and other insisted that as zlib was in system, we shouldn’t depend on it at all. I disagree, and I would like to know why we can’t depend on a system package, but whatever. Somewhat related: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2575 Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Projects and subproject status
About portage: Current status: The portage project is mostly fine, though we've missed my original plan to release the first 2.2 test versions last year, mostly because of lack of time on my part. I hope we can fix that within the next two or three months. As Paul has already mentioned, the tools-portage subproject definitely needs more people, or we may just dissolve it completely (it has been a one man show for some time already). Some people to help with (technical) documentation would also be useful (manpages, docbook stuff, ...) Plans: - release test versions of portage-2.2, see how all the new stuff works in practice and adjust things if necessary - help to fix external tools (including gentoolkit) and documentation to fully support portage-2.2 - some ideas for the time after 2.2: * merge gentoolkit into portage * redesign some of the old APIs (dbapi, config) and implement new ones (query framework) * replace revdep-rebuild with a package set * implement a new installed-package database * new dep resolver (as always ;) * new user interface(s) * ... Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Sat, 22 Dec 2007 16:43:10 +0100 Piotr Jaroszyński [EMAIL PROTECTED] wrote: Hello, I have updated the GLEP, hopefully it is less confusing now and hence the discussion will be more technical. Still doesn't address my concerns, namely: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) - doesn't mention compability issues on the dev side (minor) Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI inside ebuild filename (.EAPI-ebuild of different?)
On Thu, 20 Dec 2007 15:50:02 +0300
Peter Volkov [EMAIL PROTECTED] wrote:
This hack is just to solve portage problem which does not ignore .ebuild
files which does not follow pkg-ver.ebuild syntax and suggested solution
is not the only solution. Other possibilities are, which I like more:
1. USE pkg-ver.EAPI-ebuild
Same thing really, just looks even messier IMO.
2. USE pkg-ver${EAPITAG}EAPI.ebuild
Here ${EAPITAG} is string to simplify parsing EAPI from
version. E.g. EAPITAG could be _eapi or EAPI or something
else.
Isn't backwards compatible in any way.
Marius
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 28 Dec 2007 23:34:44 + (UTC) Duncan [EMAIL PROTECTED] wrote: I understand the ban on non-EAPI-0 features in in-tree profiles, since users could be using old PMs, but it's fine using them in /etc/portage/*, provided one has upgraded to an appropriately compatible PM, correct? Yes (in case of portage). Marius -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 28 Dec 2007 12:03:12 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Thu, 27 Dec 2007 23:26:27 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Marius Mauch wrote: Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? The restricted definition is certainly OK, but I'm not convinced that the restriction is necessary. There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. The issue is with comparison rules. For the current use case that's not an issue as it's simply a superset, so we could just use the new rules for everything. But if the rules are changed in an incompatible way, which rules would be used to compare version(EAPI_X) with version(EAPI_Y)? Ditto for naming rules. Those are even more of an issue, as they apply before we know the eventual EAPI (need to access the category/package directory before you can parse the ebuild filename) Marius -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 31 Dec 2007 15:09:33 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 31 Dec 2007 15:46:06 +0100 Marius Mauch [EMAIL PROTECTED] wrote: The issue is with comparison rules. For the current use case that's not an issue as it's simply a superset, so we could just use the new rules for everything. But if the rules are changed in an incompatible way, which rules would be used to compare version(EAPI_X) with version(EAPI_Y)? You pretty much have to have a way of mapping an EAPI version onto an absolute version if you want to handle it sanely. Right, and that's likely to cause a mess in the long run IMO. Ditto for naming rules. Those are even more of an issue, as they apply before we know the eventual EAPI (need to access the category/package directory before you can parse the ebuild filename) Mmm, no. You have some concept of a superset of all supported naming rules, then refine once you've extracted the EAPI. Assuming the current package manager supports all used EAPIs, otherwise a formerly invalid name could still break it. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Mon, 31 Dec 2007 14:40:57 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 31 Dec 2007 15:33:51 +0100 Marius Mauch [EMAIL PROTECTED] wrote: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) That already happened with EAPI 1 and slot deps. Not really. Just because slot deps are included in EAPI 1 doesn't mean that they have to be supported everywhere. The complete atom specification should be a separate versioned document, and EAPI references version X of it and the profile specification references version Y, simple as that. Marius -- [EMAIL PROTECTED] mailing list
