Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Friday 04 November 2005 23:26, Xavier Neys wrote: > Nathan L. Adams wrote: > > One source: http://errata.gentoo.org/ > > > > Push that out to as many alternate sources as you like (RSS feeds, > > summaries in emerge --news, forums post, etc.), but make it known that > > the website is *the* source (your alternate sources should point back to > > it). > > I beg to differ. The tree should be the central point because it's the only > known place where all users can receive relevant information on and for > each and every system they maintain right before they upgrade. > The warning and the logic that triggers its display should be part of > Portage. Sometimes, all that would need to be displayed is "run foo to fix > bar" or "Please do read http://bleh _before_ you upgrade foo". > > If an "Upgrade guide to foo/bar for Gentoo" is required, you need an author > to write it, not extra code or an extra web site. I probably shouldn't have included the sarcastic comment in my only other reply to this thread, but the rest of it was completely serious. People are under the mistaken impression that the ebuild tree is required to use portage. This is wrong and will become more and more wrong as time goes by. If there is not a specific need for this news stuff to go into the tree then it shouldn't be there. If there is a specific need (ie. it is tied to packages) what difference is there to the existing ChangeLog? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Saturday 05 November 2005 03:53, Alec Joseph Warner wrote: > As far as including news in the tree goes, news is repository bound > information. Each repository may in fact have relevant news, and in > preparation for multiple repositories this is how the news should be > handled. It goes with the rest of the repo-specific information. That > is why it should be in the tree. I seem to be repeating myself... What's an example of repository-specific non-package-specific news? Why does `emerge --changelog` not suffice for package-specific news? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
> A more reliable way of getting news of critical updates out to users is > required to avoid repeats of the various recent upgrade debacles. Examples of the "recent upgrade debacles" aren't needed, but you should at least state some of the outcomes that occurred, whether it be unscheduled downtime, data corruption or whatever. > Preemptive > Users should be told of changes *before* they break the user's system, > after the damage has already been done. s/after/when/ perhaps? This sentence takes a couple of reads... > No user subscription required > It has already been demonstrated [#forums-whining]_ that many users do > not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. Could you use "complaints" instead of "whining" or whatever will represent what the users are doing from an unbiased point of view please? > Quality control > There should be some way to ensure that badly written or irrelevant > messages are not sent out, for example by inexperienced developers, > those whose English language skills are below par or morons. "morons" is not needed either. > The following headers are used for filtering. If none of these headers are > specified, the news item is displayed for all users. Otherwise, the news > item is displayed if *at least one* header matches. It would seem more useful if the headers were sorted into the three classes first. A news item would then only be displayed if a header from the class matches or the class is empty. This would allow for rules such as "net-www/apache is installed and the keyword is either mips or sparc". > ``Display-If-Installed:`` > A dependency atom or simple package name (for example, > `` package specified installed, the news item should be displayed. > > ``Display-If-Keyword:`` > A keyword [#glep-22]_ name, for example ``mips``. If the user is on the > arch in question, the news item should be displayed. > > ``Display-If-Profile:`` > A profile path, for example ``default-linux/sparc/sparc64/server``. If > the user is using the exact profile in question, the news item should be > displayed. This header may be used to replace ``deprecated`` files in > the future. Isn't keyword just a generalization of profile? Why have both? > Thus, all proposed news items must be posted to the ``gentoo-dev`` or > ``gentoo-core`` mailing list, and ``Cc:``\ed to [EMAIL PROTECTED] at least > 72 hours before being committed (exceptions may be made in exceptional > circumstances). Any complaints regarding wording or clarity **must** be > addressed before the news item goes live. Why gentoo-core? It's a news item; it's purpose is to be made public. > Client Side > ''''''''''' > > Whenever relevant unread news items are found, ``emerge`` will copy or > symlink the news file into ``/var/lib/gentoo/news/``. > > Notification that new relevant news items will be displayed via the > ``emerge`` tool in a similar way to the existing "configuration files need > updating" messages: > > :: > > * Important: 3 config files in /etc need updating. > * Type emerge --help config to learn how to update config files. > > * Important: there are 5 unread news items. > * Type emerge --help news to learn how to read news files. > > The unread news message will also be displayed immediately after an > ``emerge sync``. > > Portage may also warn of unread news items using, for example, a red flashy > before actions such as merging a package. > > Portage must keep track of news items which have already been installed to > avoid repeatedly reinstalling a deleted news item. Why put this in portage at all? Post sync hooks will likely be available in 2.0.54. If adding hooks were as easy as adding a file to a portage config directory, would adding the package that does the above to the system package set be enough to force this new information dispersal method on users? > Once a news item is 'installed', third party tools (or a traditional Unix > pager and ``rm``) can be used to display and view the news files. An > ``eselect`` [#eselect]_ module shall be created as the 'suggested' display > tool; other display tools (for example, a news to email forwarder, which > would be ideal for users who sync on a cron) are left as options for those > who desire them -- the simple file format make this relatively simple. This is just more reasoning that nothing should be added to portage at all... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
On Saturday 05 November 2005 22:24, Brian Harring wrote: > On Sat, Nov 05, 2005 at 10:18:14PM +0900, Jason Stubbs wrote: > > > ``Display-If-Installed:`` > > >   A dependency atom or simple package name (for example, > > >   `` > > the   package specified installed, the news item should be > > > displayed. > > > > > > ``Display-If-Keyword:`` > > >   A keyword [#glep-22]_ name, for example ``mips``. If the user is > > > on the   arch in question, the news item should be displayed. > > > > > > ``Display-If-Profile:`` > > >   A profile path, for example > > > ``default-linux/sparc/sparc64/server``. If   the user is using the > > > exact profile in question, the news item should be   displayed. > > > This header may be used to replace ``deprecated`` files in   the > > > future. Where'd those funny "A"s come from? > > Isn't keyword just a generalization of profile? Why have both? > > You would have to specify a common subprofile, and have the code know > to dig through the ancestors of a profile. "If a user is using the exact profile in question"... Common subprofiles seem to be irrelevant. I was going to bring up that point as well, but then I recalled that some utilized profiles have children also (such as amd64/2005.1 and amd64/2005.1/no-multilib). If subprofiles were also picked up, there would be no way to specify a news item that only pertained to multilib amd64 systems. > Breaks down when dealing with profiles that lack a common base > (conversion from flat profiles to cascaded for example). My understanding is that each class of header can appear multiple times. As far as I can tell Display-If-Keyword would just prevent having to specify Display-If-Profile for each profile of the keyword specified. I'd just like to clarify that it has no purpose beyond that. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
On Sunday 06 November 2005 02:57, Ciaran McCreesh wrote: > On Sat, 5 Nov 2005 22:18:14 +0900 Jason Stubbs <[EMAIL PROTECTED]> > | > The following headers are used for filtering. If none of these > | > headers are specified, the news item is displayed for all users. > | > Otherwise, the news item is displayed if *at least one* header > | > matches. > | > | It would seem more useful if the headers were sorted into the three > | classes first. A news item would then only be displayed if a header > | from the class matches or the class is empty. This would allow for > | rules such as "net-www/apache is installed and the keyword is either > | mips or sparc". > > Hrm. I'll need to think about that. But it's starting to sound nicer > than the and/or/none voodoo I'd removed previously. My sentences aren't making much sense either, even if you got my intention anyway. ;) A news item would then only be displayed if a header from the class matches or the class is empty *for each class*. > | Isn't keyword just a generalization of profile? Why have both? > > Simplicity. Ok. Just confirming. > | > Thus, all proposed news items must be posted to the ``gentoo-dev`` > | > or ``gentoo-core`` mailing list, and ``Cc:``\ed to > | > [EMAIL PROTECTED] at least 72 hours before being committed > | > (exceptions may be made in exceptional circumstances). Any > | > complaints regarding wording or clarity **must** be addressed > | > before the news item goes live. > | > | Why gentoo-core? It's a news item; it's purpose is to be made public. > > Possible security concerns. Hopefully this will never happen. Ok. > | Why put this in portage at all? Post sync hooks will likely be > | available in 2.0.54. If adding hooks were as easy as adding a file to > | a portage config directory, would adding the package that does the > | above to the system package set be enough to force this new > | information dispersal method on users? > > Performance. I have a bash script which does the installs that could > easily be called by a hook, but it has to call portageq quite a bit. > Otherwise a hook would be fine... Possibly it's fine anyway? The script could be converted to Python. Or we can have a go at speeding up portageq a bit. (Or both ;). It's just that there's only a small part of integrated into portage as far as the current GLEP goes, which then partially locks people out of working with the news items in alternative ways... Could you send over the bash version of the post-sync script? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Monday 07 November 2005 19:11, Paul de Vrieze wrote: > On Saturday 05 November 2005 06:34, Alec Warner wrote: > > emerge --changelog has no 'official' format. I believe echangelog > > actually puts the changes in the correct format for emerge -l to read, > > however not everyone uses echangelog. Many developers commit in an > > incompatable syntax causing the parsing to fail. This I believe, is an > > implementation issue. Obviously if someone is trying to get an upgrade > > guide to users they aren't going to commit in an incompatable format. > > I would also like to add that the changelog has too much information to be > usefull as a news source. In all honesty, when I'm emerging a new version > of a package I'm not interested in keyword bumps, small cosmetic changes, > added auxiliary scripts or documentation. These are all documented (and > should be) in the changelog. If I update my system however, I'm mainly > interested in knowing whether something is going to break. News would be > a way to provide this knowledge to a user in an as concise as possible > way. So what's the point of the ChangeLog again? Move load from the CVS server and onto the rsync servers? (Don't answer that - just beating a dead horse ;) I'm really just against having it in emerge, especially with the current suggestion of portage just doing a little bit of maintenance work for external tools and nothing else. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.defaults ( auto-use )
On Monday 07 November 2005 19:25, Henrik Brix Andersen wrote: > On Mon, Nov 07, 2005 at 02:05:37AM -0500, Alec Warner wrote: > > Could we by chance, mandate some sort of comment field in that file not > > unlike package.mask? > > Sounds like a really good idea to me. Will this require any > modifications to portage, or will it automagically ignore # comments > in that file? Lines beginning with # are ignored. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Tuesday 08 November 2005 01:06, Grant Goodyear wrote: > Jason Stubbs wrote: [Mon Nov 07 2005, 06:37:10AM CST] > > I'm really just against having it in emerge, especially with the current > > suggestion of portage just doing a little bit of maintenance work for > > external tools and nothing else. > > I'm not sure exactly what you're arguing here. Is it just that you > think that the news stuff should be a post-sync hook instead of being > triggered explicitly by "emerge"? I just wrote several paragraphs but that got me thinking so I deleted 'em. Ok. There's two levels of APIs here. There's the post-sync stuff which utilizes portage's API. There'll never be any need for portage to utilize the post-sync stuff that I can think of; if there is, that's a reason for putting it into portage. The second layer is between the post-sync stuff and the news readers. Here we have a problem. As Brian mentioned, multiple independent repositories will be supported and each should be allowed to have it's own independent set of news items. Multiple repositories will bring new (or completely replace) portage APIs. Hence, the post-sync stuff will have to accomodate. Yet, that's going to propogate into the post-sync component's API provided for the readers. Multiple independent repositories is just one change that we know is going to throw a spanner in the works. There'll likely be others. Hmm, I think I've just discovered what's unsettling about all this. We're being asked to throw something into portage that'll do XYZ to support external tools, yet we are guaranteed to break the XYZ. I guess I'd be happy with portage doing it and responsibility for compatibility staying with portage as long as we can decide/lead how the external tools gains access to the information. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two
On Saturday 12 November 2005 07:19, Stuart Herbert wrote: > When we have emerge --news done, I keep seeing references to "emerge --news" but at the same time am seeing that news readers are external. What exactly is `emerge --news` meant to do? Print out "You've got news!"? Manage some external database? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Plugin framework
I've had a go at creating a generic plugin framework for portage. The attached
patch contains:
* plugins/__init__.py that does plugin searching and loading.
* plugins/cache/__init__.py which specifies what class cache plugins must
derive from.
* cache/{anydbm,flat_hash,flat_list,metadata,sqlite}.py copied to
plugins/cache/ with imports adjusted and classes renamed to match their
filenames.
* portage.py edits to the config class to make use of the framework.
Essentially, plugins.registry gives dict access to modules under plugins/. To
give an example, the plugins.cache.anydbm.anydbm class can be accessed via
plugins.repository["cache"]["anydbm"].
In loading, I'm iterating through sys.path and chopping that out from the
detected module's path. I didn't need to do this when I was first testing the
module loader, however. After integrating it with portage I was getting
"module not found" errors. If anybody knows why that is, I'll get rid of that
iteration. To be clear, the following doesn't work only when running from
portage (regardless of the path used):
python -c '__import__("/usr/lib/portage/pym/cache")'
diff -uNr portage-orig/pym/plugins/__init__.py portage-plugin-framework/pym/plugins/__init__.py
--- portage-orig/pym/plugins/__init__.py 1970-01-01 09:00:00.0 +0900
+++ portage-plugin-framework/pym/plugins/__init__.py 2005-11-12 21:52:15.0 +0900
@@ -0,0 +1,80 @@
+class registry:
+
+ class _plugin_loader:
+
+ def __init__(self, path):
+ try:
+import sys
+for prefix in sys.path:
+ if path.startswith(prefix):
+ mod_name = path[len(prefix)+1:]
+ self._plugin = __import__(mod_name)
+ getattr(self._plugin, "plugin_class")
+ break
+ except (ImportError, AttributeError), e:
+raise ImportError
+ self._path = path
+ self._loaded = {}
+
+ def __getitem__(self, name):
+ if name in self._loaded:
+return self._loaded[name]
+ try:
+import os
+plugin_path = os.path.join(self._path, name)
+import sys
+for prefix in sys.path:
+ if plugin_path.startswith(prefix):
+ plugin_name = plugin_path[len(prefix)+1:]
+ plugin = __import__(plugin_name)
+ break
+plugin = getattr(plugin, name)
+if issubclass(plugin, self._plugin.plugin_class):
+ self._loaded[name] = plugin
+ return plugin
+ except (ImportError, AttributeError), e:
+pass
+ raise KeyError(name)
+
+ def keys(self):
+ import os
+ for name in os.listdir(self._path):
+(name, ext) = os.path.splitext(name)
+if name.startswith("_") or not ext.startswith(".py"):
+ continue
+if name not in self._loaded:
+ try:
+ self[name]
+ except KeyError:
+ pass
+ keys = self._loaded.keys()
+ keys.sort()
+ return keys
+
+ def __init__(self):
+ import os
+ self._path = os.path.dirname(__file__)
+ self._loaded = {}
+
+ def __getitem__(self, name):
+ if name not in self._loaded:
+ try:
+import os
+self._loaded[name] = self._plugin_loader(os.path.join(self._path, name))
+ except ImportError, e:
+raise KeyError, name
+ return self._loaded[name]
+
+ def keys(self):
+ import os
+ for name in os.listdir(self._path):
+ if name not in self._loaded:
+try:
+ self[name]
+except KeyError:
+ pass
+ keys = self._loaded.keys()
+ keys.sort()
+ return keys
+
+registry = registry()
diff -uNr portage-orig/pym/plugins/cache/__init__.py portage-plugin-framework/pym/plugins/cache/__init__.py
--- portage-orig/pym/plugins/cache/__init__.py 1970-01-01 09:00:00.0 +0900
+++ portage-plugin-framework/pym/plugins/cache/__init__.py 2005-11-12 21:52:15.0 +0900
@@ -0,0 +1 @@
+from cache.template import database as plugin_class
diff -uNr portage-orig/pym/plugins/cache/anydbm.py portage-plugin-framework/pym/plugins/cache/anydbm.py
--- portage-orig/pym/plugins/cache/anydbm.py 1970-01-01 09:00:00.0 +0900
+++ portage-plugin-framework/pym/plugins/cache/anydbm.py 2005-11-12 21:52:15.0 +0900
@@ -0,0 +1,75 @@
+# Copyright: 2005 Gentoo Foundation
+# Author(s): Brian Harring ([EMAIL PROTECTED])
+# License: GPL2
+# $Id: anydbm.py 1911 2005-08-25 03:44:21Z ferringb $
+
+anydbm_module = __import__("anydbm")
+try:
+ import cPickle as pickle
+except ImportError:
+ import pickle
+import os
+from cache import fs_template
+from cache import cache_errors
+
+
+class anydbm(fs_template.FsBased):
+
+ autocommits = True
+ cleanse_keys = True
+
+ def __init__(self, *args, **config):
+ super(anydbm,self).__init__(*args, **config)
+
+ default_db = config.get("dbtype","anydbm")
+ if not default_db.startswith("."):
+ default_db = '.' + default_db
+
+ self._db_path = os.path.join(self.location, fs_template.gen_label(self.location, self.label)+default_db)
+ self.__db = None
+ try:
+ self.__db = anydbm_module.open(self._db_path, "w", self._perms)
+
+ except anydbm_module.error:
+ # XXX handle this at some point
+ try:
+self._ensure_dirs()
+self._ensure_dirs(self._db_path)
+
Re: [gentoo-dev] Plugin framework
On Saturday 12 November 2005 22:11, Jason Stubbs wrote: > I've had a go at creating a generic plugin framework for portage. The > attached patch contains: Gah! Apologies again. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two
On Sunday 13 November 2005 00:34, Chris Gianelloni wrote: > On Sat, 2005-11-12 at 13:39 +0900, Jason Stubbs wrote: > > On Saturday 12 November 2005 07:19, Stuart Herbert wrote: > > > When we have emerge --news done, > > > > I keep seeing references to "emerge --news" but at the same time am > > seeing that news readers are external. What exactly is `emerge --news` > > meant to do? Print out "You've got news!"? Manage some external database? > > It is my opinion that the news reading application need not be > integrated into portage. As far as I have understood it, the only real > thing that anyone has required portage itself to do is to > *automatically* spit out "You have $n unread news messages. Please use > $bleh to read them" at certain times (after sync, after --pretend, > before/after a merge). I don't see this as being something very > complex. I would assume that some extra code would need to be written > into the sync code somewhere to sort the messages. This, I get. What I'm wondering about is the `emerge --news` that is referred to every so often. > I wouldn't mind seeing something along the lines of /var/db/news > directory (or something repo specific, whatever) that has a pretty > simple format... > > -mm-dd-$blah-$lang.txt.unread > -mm-dd-$blah-$lang.txt.read > > When you delete a message, it is gone. This means an external news > reader (enews anyone?) that basically has the capability to read, skip, > or delete these news items. > > I think this would be pretty simple to get done and covers the problem > of messages being read or unread. Of course, this is all just an idea, > so feel free to blow holes all in it. ;] To be honest, this is the part that I don't like the most. Integrating code into portage to copy files here and there based on some predefined rules and news readers reading and renaming files based on some predefined rules... A filesystem based API just doesn't seem very robust to change. I'd prefer that either the post-sync handling code is not integrated into portage and portage just triggers some external script - or - portage exposes an API (via python and bash) for accessing and updating news items. I'd prefer the latter but I get the impression that most prefer the former. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] FEATURES=test and the internet
On Thursday 17 November 2005 22:17, Michael Cummings wrote: > Ciaran McCreesh wrote: > > https://bugs.gentoo.org/show_bug.cgi?id=82513 > > Anyone know why jstubbs closed the bug without comment? I don't see > where it was particualrly resolved. There are several requests on the bug, the majority are now fixed and everybody (at least within the portage team) is agreed that FEATURES should not be added to USE_EXPAND. Essentially, I didn't take the time to read through all the follow-ups related (and unrelated) to the one request that wasn't addressed. A comment didn't seem to be required as it appeared to be one of those bugs that are left open for months after being fixed. Reopen and adjust the summary to something relevant if you like. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] FEATURES=test and the internet
On Friday 18 November 2005 22:20, Michael Cummings wrote: > Jason Stubbs wrote: > > There are several requests on the bug, the majority are now fixed and > > > > everybody (at least within the portage team) is agreed that FEATURES > > should not be added to USE_EXPAND. Essentially, I didn't take the time > > to read through all the follow-ups related (and unrelated) to the one > > request that wasn't addressed. A comment didn't seem to be required as > > it appeared to be one of those bugs that are left open for months after > > being fixed. Reopen and adjust the summary to something relevant if > > you like. > > There's a reason that bugzilla mandates you provide a comment before > closing a bug - even if its to say what you just did. "Resolved - Fixed"? > While the bug may have devolved, the original gist still stands - can we > have a means of having FEATURES="maktest" translated into a use flag > without requiring users to set both? (see my last comment in the bug for > my interest on the matter :) I'm not advocating a full FEATURE explosion > or anything of the like, and maybe this is something that should have > been a USE flag and not a FEATURE to begin with, but its where we're at. The last discussion that was had ended up with a TDEPEND, but that doesn't cover the additional SRC_URI requirements. Besides SRC_URI, are there any other requirements that might sneak in later on? > I can of course take this over to bugzilla if you'd prefer :) Nah, let's get it in the open (again) and get it dealt with. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] FEATURES=test and the internet
On Saturday 19 November 2005 01:13, Michael Cummings wrote: > Jason Stubbs wrote: > > "Resolved - Fixed"? > > Hmmm, might have been aq epiphany quirk (wouldn't be the first) - when i > looked there was no comment indicated. Nope. I wrote ".". Bugs wrote the above for me. ;) > > The last discussion that was had ended up with a TDEPEND, but that > > doesn't cover the additional SRC_URI requirements. Besides SRC_URI, are > > there any other requirements that might sneak in later on? > > and this is the other reason i took it off -dev - so i don't sound like > an idiot -there's a TPDEPEND now?? That would 100% cover my needs, since > these are testing depends. A TDEPEND? Nope, not yet. It's just a possible solution that won't require overloading USE flags for internal purposes further. > > Nah, let's get it in the open (again) and get it dealt with. > > OK, so i violated that, but now i'm wondering if my needs are already > covered (hey, could happen) :) Not just yet... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Email subdomain
On Saturday 19 November 2005 17:39, Duncan wrote: > 8) Infra has expressed reluctance, and asks the question if we accept this > one, where might it end? Legitimate question, but AFAICT, the question is > no longer whether this is a good idea or not as it's already been decided > to go ahead, but rather one of implementation, once the subdomain is > settled upon. If implementation details have not yet been worked out, that part of the GLEP and any approval of it is essentially void. In fact, reading over the GLEP as is currently posted on the website, it's absolutely full of holes. Here's a quick list from less than a minutes glancing: A) @(subdomain_to_be_determined).gentoo.org is indeterminate B) What should be done with the @(subdomain_to_be_determined) email after an AT becomes a full dev (and presumably gets a @gentoo.org address)? For how long? C) How does one become a Lead AT/HT? D) What is a Stategic AT Lead? E) What criteria must an AT meet to be able to receive the shortened probationary when moving on to becoming a full dev? F) Do the various usages of "should" and "could" mean must? And a few more after reading over it again: G) What criteria must be met during the inital 30 day mentoring period? H) What criteria are there for maintaining one's status as an AT? I) What input does DevRel have in the process of becoming an AT? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Email subdomain
On Saturday 19 November 2005 20:09, Thierry Carrez wrote: > Jakub Moc wrote: > > Now, we might we perhaps move the focus to more important issues jstubbs > > mentioned in his last email, expecting that any implementation of the now > > approved GLEP wrt the email addresses won't be pushed in a similar way > > the whole revised GLEP has been, until infra issues and usefulness of > > this are sorted out/reconsidered at least. > > 75% of his email is about things that were in the original GLEP. Why > didn't he raise his voice at that time ? As Ciaran said in the other thread, I was waiting for (at least) the next round. I saw very little agreement in the original thread so didn't give it the time for a viewing; just as in the `emerge --news` thread. I honestly don't see why you're defending the council's hasty decision when the council members all knew that the timing was bad while the decision was being hasted. The statement that it wouldn't happen again is evidence of that. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Email subdomain
On Sunday 20 November 2005 08:46, Mike Frysinger wrote: > On Sat, Nov 19, 2005 at 06:23:41PM +0900, Jason Stubbs wrote: > > B) What should be done with the @(subdomain_to_be_determined) email after > > an AT becomes a full dev (and presumably gets a @gentoo.org address)? For > > how long? > > this is in the GLEP ... it clearly states that it will become a forward > to their new @gentoo.org address. the implied part is that when the > user feels they no longer need it, they punt it. Missed it. Was skimming too quickly. > > E) What criteria must an AT meet to be able to receive the shortened > >probationary when moving on to becoming a full dev? > > they express interest in becoming a full dev at which point they enter > the normal 'becoming a dev' recruitment track. why should they have to > do something special to become a normal dev ? all devs are allowed to > be AT's. "the mentoring period should be shortened to a minimum of two weeks" was what I was referring to. > > G) What criteria must be met during the inital 30 day mentoring period? > > H) What criteria are there for maintaining one's status as an AT? > > I) What input does DevRel have in the process of becoming an AT? > > http://www.gentoo.org/proj/en/base/amd64/tests/index.xml Err.. what's that got to do with the GLEP? But none of this really matters apparently because the GLEP has been approved and I'm just one of the "people that don't have an opinion on the subject but were watching the council for its first bad step to be able to accuse it of abuse of power or worse". -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
On Wednesday 23 November 2005 00:46, Donnie Berkholz wrote: > Doug Goldstein wrote: > > I thought GLEP 37 was a way out kind of thing. Like several months if > > not a year before it can be done. > > I figured about the same, but > https://bugs.gentoo.org/show_bug.cgi?id=112896#c16 begs to differ. The glep was originally posted 30th April... The idea was already fairly solid at that time and required minimal changes to portage for it to "just work". Pretty much only one actually - the hardcoded 'sanity check' of not being able to install packages of category "virtual" was removed. Hence, as per the backwards compatibility section of the glep, all current portages are capable of handling virtuals that are regular packages. The largest holdup was waiting for backwards compatibility to become viable. There are really only two other parts to the glep; consistency checking and user overrides. The current method of overriding will still work fine and only becomes an issue when the first virtual that covers a set of packages comes into existence. As for consistency checking, it has a relatively small chance of being useful in my opinion. Take the following: # emerge virtual/x11 # emerge -C x11-base/xorg-x11 # emerge x11-libs/qt (Whoops!) In other words, it's a situtation that is possible already. The solution is to always use --deep when calculating dependencies, which I'm working on at the moment. There are a couple of other portage-side implementation issues that have come up, but the more difficult ones have become clearer over time. I'll dust of the GLEP and repost it later this week and see if we can't get it finalized... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multi hash support in portage - status
On Thursday 24 November 2005 09:32, Marius Mauch wrote: > On Thu, 24 Nov 2005 01:04:32 +0100 > > Marius Mauch <[EMAIL PROTECTED]> wrote: > > Ok I have three modifications that are pending to go into portage: > > - The first simply enables creation of SHA1 checksums (and others if > > implemented like with the second mod), if you want to try it yourself > > see the attached patch. Looking through CVS, this was supported in at least portage-2.0.51_rc10 right? This implies that the only versions that will have problems are 2.0.50-r11 and under? If so, they've already got the cascaded profile problem so breaking things a little more won't hurt much. ;) Seriously though, those that can't handle the new format would have to do what? Regenerate digests for sandbox and portage and then emerge each of them with --oneshot? Am I missing anything else there? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multi hash support in portage - status
On Thursday 24 November 2005 10:07, Marius Mauch wrote: > On Thu, 24 Nov 2005 09:49:20 +0900 > > Jason Stubbs <[EMAIL PROTECTED]> wrote: > > On Thursday 24 November 2005 09:32, Marius Mauch wrote: > > > On Thu, 24 Nov 2005 01:04:32 +0100 > > > > > > Marius Mauch <[EMAIL PROTECTED]> wrote: > > > > Ok I have three modifications that are pending to go into portage: > > > > - The first simply enables creation of SHA1 checksums (and others > > > > if implemented like with the second mod), if you want to try it > > > > yourself see the attached patch. > > > > Looking through CVS, this was supported in at least > > portage-2.0.51_rc10 right? This implies that the only versions that > > will have problems are 2.0.50-r11 and under? If so, they've already > > got the cascaded profile problem so breaking things a little more > > won't hurt much. ;) > > > > Seriously though, those that can't handle the new format would have > > to do what? Regenerate digests for sandbox and portage and then > > emerge each of them with --oneshot? Am I missing anything else there? > > Nope, not missing anything. Thought I said it, compability isn't a > reason to hold this up anymore, only asking if people want multi-hashes > now at the expense of a bigger tree when Manifest2 comes along. I'm referring to portage-2.0.50 and below. What exactly needs to be done by those few that are still using it to upgrade to a better portage after it dies on finding SHA1 sums in portage's digest? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Friday 25 November 2005 08:58, Ciaran McCreesh wrote: > Of course, if FEATURES were in the USE expand list, you could use > ! features_noman ? ( ) ... All the way up until FEATURES="noman" is changed to FEATURES="man"... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multi hash support in portage - status
On Saturday 26 November 2005 11:12, Marius Mauch wrote: > On Thu, 24 Nov 2005 01:04:32 +0100 > > Marius Mauch <[EMAIL PROTECTED]> wrote: > > Would you rather have now the ability to create multi-hash digests and > > Manifests with the result of a short and mid-term larger portage tree > > (in the long term the format will be phased out hopefully) or rather > > wait for Manifest2 support (which will definitely include multi hash > > support)? > > Ok, so far two votes for now and one vote for later, unless this > changes significantly I'll ask the council to add the decision to the > agenda for its next meeting (sorry, just don't want to be the bad guy > here ;) /me adds a vote for later to even it up. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Removal of auto-use in portage-2.0.54
On Sunday 27 November 2005 01:48, Henrik Brix Andersen wrote:
> On Sat, Nov 26, 2005 at 05:12:45PM +0200, Marius Mauch wrote:
> > As I said earlier, we'd like to get rid of the nasty auto-use feature,
> > including the support for the USE_ORDER variable. Right now we intend
> > this for 2.0.54 (might not be the final version number) unless there are
> > major objections to it.
>
> What will happen to the USE flags currently in use.defaults when this
> is removed?
It will turn off unless it is enabled somewhere else.
> Perhaps some of them be moved to the profiles instead?
This is more of a releng/basesystem question rather than a portage question.
Makes no difference to me as a user as I have USE="-* ..." in make.conf. ;)
> I'm mostly concerned about the 'udev' USE flag. Some packages rely on
> this to be able to function correctly on an udev enabled system.
> Since udev seems to be the default choice for our default-linux
> profiles, it would make sense to also set USE=udev in those profiles?
Message logging will come in at the same time so it might be better to do
something like:
portageq has_version ${ROOT} sys-fs/udev && use !udev && (
ewarn "You have udev installed but do not the udev USE flag enabled."
ewarn "${PN} might behave incorrectly."
)
Except with better bash style of course.. But that's just what I'd do. Once
proper logging goes in, it'd be a good idea for policies on things like this
to be developed.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 22:09, Ned Ludd wrote:
> On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
> > On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
> > > Except that no{man,info,doc} are on the to-die list anyway.
> >
> > They are very valuable features and quite easy to use without mucking
> > with INSTALL_MASK. I'm against this change without some justification.
>
> further investigation shows that you can't simply get rid of these as
> several core ebuilds use the feature to control the creation of
> packages. A quick grep shows that several ebuilds do stuff like.
> has noman FEATURES && do_stuff
>
> openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
> no{man,info,doc} FEATURES= already.
Core packages or not, they are all broken. When the requirement came up, the
respective maintainers should have spoken up so that a proper solution could
be found. When are the quick hacks going to stop? :|
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 23:50, Diego 'Flameeyes' Pettenò wrote: > On Sunday 27 November 2005 15:39, Jason Stubbs wrote: > > Core packages or not, they are all broken. When the requirement came up, > > the respective maintainers should have spoken up so that a proper > > solution could be found. When are the quick hacks going to stop? :| > > Is my mail enough as a speak-up for finding a proper solution? :P No because you haven't listed any requirements beyond those that solar has already pointed out. :P -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 23:43, Jakub Moc wrote:
> 27.11.2005, 15:39:48, Jason Stubbs wrote:
> > On Sunday 27 November 2005 22:09, Ned Ludd wrote:
> >> On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
> >> > On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
> >> > > Except that no{man,info,doc} are on the to-die list anyway.
> >> >
> >> > They are very valuable features and quite easy to use without mucking
> >> > with INSTALL_MASK. I'm against this change without some justification.
> >>
> >> further investigation shows that you can't simply get rid of these as
> >> several core ebuilds use the feature to control the creation of
> >> packages. A quick grep shows that several ebuilds do stuff like.
> >> has noman FEATURES && do_stuff
> >>
> >> openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
> >> no{man,info,doc} FEATURES= already.
> >
> > Core packages or not, they are all broken. When the requirement came up,
> > the respective maintainers should have spoken up so that a proper
> > solution could be found. When are the quick hacks going to stop? :|
>
> I can't see why exactly do we need to get rid of useful features? :-(
Nobody said anything about getting rid of the features. The only thing that
has been stated is that FEATURES="noman" cannot be relied upon to mean that
portage won't install man pages or vice-versa.
There are three possibilities that I can see:
1) FEATURES="noman" becomes FEATURES="man"
2) FEATURES="noman" is dropped in favour of INSTALL_MASK="/usr/share/man"
3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages"
In light of the above requirements and the fact that dyn_* will likely be
moved into the tree down the track, #3 seems to be the best in my mind.
Similarly, it would solve the previously discussed problems related to
FEATURES="test".
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 23:50, Diego 'Flameeyes' Pettenò wrote: > On Sunday 27 November 2005 15:39, Jason Stubbs wrote: > > Core packages or not, they are all broken. When the requirement came up, > > the respective maintainers should have spoken up so that a proper > > solution could be found. When are the quick hacks going to stop? :| > > Is my mail enough as a speak-up for finding a proper solution? :P Err.. Apologies. I has forgotten that you were the one to start the thread. :( -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Monday 28 November 2005 00:05, Jason Stubbs wrote: > 3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages" > > In light of the above requirements and the fact that dyn_* will likely be > moved into the tree down the track, #3 seems to be the best in my mind. > Similarly, it would solve the previously discussed problems related to > FEATURES="test". I'd be very interested in people's thoughts on this. The more I think about it, the more I think it's the most appropriate solution. Nothing in FEATURES="noman nodoc noinfo test" affects portage whatsoever other than "noinfo" which (only recently) prevents emerge from regenerating info indexes. That one could be handled by a hook (although not yet available) and the rest could easily be switched to USE flags. Anybody see any flaws? Anybody want (shudders) a GLEP? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86
On Saturday 03 December 2005 21:47, Duncan wrote: > Mark Loeser posted <[EMAIL PROTECTED]>, excerpted > > below, on Fri, 02 Dec 2005 16:55:23 -0500: > > [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml > > Reading this reminds me of a question I've had since I tried emerge -eav > world last time: > > When portage merges, it stops the emerge process, updates its metadata or > whatever, then restarts the process. With the -e in there, at least here, > it reissued the same command over again, thereby restarting the process > from the beginning and of course, upon getting to portage, looping yet > again! This is incorrect. Portage should only restart if the version that was merged does not match the internally recorded version. There was one or two releases that had an incorrect internal version but not for at least a year. However, if the version has changed and portage does restart itself then any packages listed before portage will be merged again. > Maybe it was because I was using -KuD also, to remerge/upgrade from binary > packages? (Hard disk trouble, I was remerging the binary packages to > bring up2date an old installation snapshot.) Perhaps you were using one of the broken versions? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-portage-dev] .53, .54 and beyond...
On Tuesday 06 December 2005 21:37, Alec Warner wrote: > Jason Stubbs wrote: > > On Tuesday 06 December 2005 11:17, Ned Ludd wrote: > > > On Mon, 2005-12-05 at 23:06 +0900, Jason Stubbs wrote: > > > > Okay, new suggestion. > > > > > > > > Postpone the cache rewrite from above. Have only the minimal mods > > > > necessary to fix the PORT_LOGDIR/tee bug. Include the other two as is. > > > > That would be 2.0.54 as per the attached patch. Get that out soon and > > > > get trunk out masked at around the same time. As soon as 2.0.54 goes > > > > stable put trunk into ~arch. However, instead of ~arch meaning > > > > "regression fixes only" we could just limit it to "minor changes only" > > > > (ie. no big refactorings, rewrites or similar high risk changes) until > > > > it is time to stable it. > > > > > > I think it would be wise to reconsider the cache fixes. I know you have > > > been away from irc for a while now and have missed the daily events, > > > but most of the people we have interacted with are expecting the cache > > > updates in .54 (alot of people complaining about the hanging at 50%) > > > > Call me wrong, but I'm feeling that the constant pulling and pushing on > > IRC causes many misjudgements. > > No I agree with you here, I just wanted reasoning because now I have > this ML thread to refer people to :p Of course, there's enough pushing and pulling on the ML here to provide food for thought. :) Ok, I've come to a conclusion and that conclusion is: We have way too much indecisiveness. I'm not sure if that's my fault or not - am I meant to be decisive? My guess is that if I were to seriously propose that question there'd be a lot of indecision about it. ;) So I'm going to make a decision and offer until Friday (Saturday in my time) for opposers to solidify and state any opposition. If there's no solid opposition, Saturday I will put current trunk into ~arch as 2.1_beta20051210. I will also post on the 2.0.53 bug that fixes are available for the ldconfig bug and the tee bug stating that we'd like to also add trunk's cache subsystem to 2.0.54 and that dependening on the next council meeting(?) the SHA1 enabling as well. Doing it this way will make the ~arch users happy straight away. If we look at it as our responsibility to get fixes and new functionality into ~arch then our jobs done and we can get back to business. As for stable users? If arch teams are willing to selectively choose what fixes they want backported to stable (when they're not prepared to move the ~arch version into stable) things will go much smoother. Of course, it would still be our responsibility to get those things backported and assert some confidence that it is working. However, once the requested fixes are backported all that needs to be done is put out the patched stable version with ~arch keywords and then leave it up to the arch teams again. Except for the slight extra burden on (which I believe many would actually find to be a blessing), it should be a win-win situation. Cross-posting to -dev@ so that some arch people can comment. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
On Wednesday 07 December 2005 17:03, Donnie Berkholz wrote: > Donnie Berkholz wrote: > | As far as progress on this issue, we're looking into adopting glep 37 > | and creating a virtual/x11 ebuild to address this. > > I've just committed virtual/x11 to the tree. See > https://bugs.gentoo.org/show_bug.cgi?id=112896 if you run into any > problems with it. > > It won't work properly with macos yet because they use a "fake" package, > so they'll have to hang on to virtual/x11 in the profiles. It should work if the listed package matches what the macos profiles have in package.provided... > I plan to remove the virtual/x11 definition from base/virtuals in a > couple of days, because this should provide a full (and non-broken) > replacement. This can be easily tested in advance by adding the following: # cat /etc/portage/profile/virtuals virtual/x11 -* -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] The deal with epkgmove
On Sunday 11 December 2005 00:56, Luca Barbato wrote: > svn so far was good but I don't know which big projects had it deployed. KDE uses subversion, depending on what you call big of course. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote: > Whenever relevant unread news items are found, the package manager will > create a file named ``/var/lib/portage/news/news.unread`` (if it does not > already exist) and append the news item identifier (eg > ``2005-11-01-yoursql-updates``) on a new line. > > .. Note:: Future changes to Portage involving support for multiple > repositories may require one news list per repository. Assuming > repositories have some kind of unique identifier, this file could be named > ``news-repoid.unread``. Repositories will definitely have a unique identifier. Perhaps it would be better to use the repository-identifing format from the beginning so that readers are forced to be forwards-compatible? Assuming the readers would then output the repository name, labeling it "gentoo" should work well... > When a news item is read, its name should be removed from the > ``news.unread`` file. News clients may add the name to a ``news.read`` file > in the same directory with the same file format. news.read should either be mandatory or not created at all. Should a user change from a reader that creates and uses the file to one that doesn't and then change back again the results will be unexpected. > * Important: there are 5 unread news items. > * Type emerge --help news to learn how to read news files. [...] > An ``eselect`` [#eselect]_ module shall be created as the 'suggested' > display tool; other display tools (for example, a news to email forwarder, > which would be ideal for users who sync on a ``cron``) are left as options > for those who desire them. By "suggested" you mean that it should be referenced in the news help? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 02:43, Ciaran McCreesh wrote: > On Sun, 11 Dec 2005 13:32:05 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Repositories will definitely have a unique identifier. Perhaps it > | would be better to use the repository-identifing format from the > | beginning so that readers are forced to be forwards-compatible? > | Assuming the readers would then output the repository name, labeling > | it "gentoo" should work well... > > *shrug* If someone creates metadata/repository_id (or whatever), I'll > go with that. Otherwise, I'm not in favour of attempting to guess how > the thing will be implemented. Repositories will be user-labelled. However, all that readers need be concerned with is how to extract the repository name from the news.unread file and how to then resolve that to a directory name, regardless of how repositories are implemented. Even before multiple respositories are properly supported, I guarantee bugs about support for this in portage overlays. With the above, we would be able to add that support. Without it, all we can do is put a big CANTFIX. > | > When a news item is read, its name should be removed from the > | > ``news.unread`` file. News clients may add the name to a > | > ``news.read`` file in the same directory with the same file format. > | > | news.read should either be mandatory or not created at all. Should a > | user change from a reader that creates and uses the file to one that > | doesn't and then change back again the results will be unexpected. > > I'm not sure that that's the case. With a news to email forwarder, for > example, it wouldn't make sense to keep track of news.read. In that case, the data should probably not be in /var/lib/portage and definitely not specified in the GLEP. It has nothing to do with portage (the app) and isn't a requirement on readers. What if a reader wants to keep track of what date an item was read on? Or any other metadata? A new file would need to be created anyway due to format constrainst placed on news.read... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 09:01, Ciaran McCreesh wrote: > On Mon, 12 Dec 2005 08:44:00 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Repositories will be user-labelled. However, all that readers need be > | concerned with is how to extract the repository name from the > | news.unread file and how to then resolve that to a directory name, > | regardless of how repositories are implemented. > > See, this is exactly why I'm not wanting to care about multiple repo > details at this point. There's no specification of how they work and > what exactly they're supposed to do, and to make matters worse the way > you seem to think they'll be handled is a really really bad way of > doing it. Regardless of what you think about the current plans for multiple repository support, the details that readers will need to know wont change. > | Even before multiple respositories are properly supported, I > | guarantee bugs about support for this in portage overlays. With the > | above, we would be able to add that support. Without it, all we can > | do is put a big CANTFIX. > > Overlay is not the same as multiple repository support. There's no difference as far as readers go. > | In that case, the data should probably not be in /var/lib/portage and > | definitely not specified in the GLEP. It has nothing to do with > | portage (the app) and isn't a requirement on readers. What if a > | reader wants to keep track of what date an item was read on? Or any > | other metadata? A new file would need to be created anyway due to > | format constrainst placed on news.read... > > Hrm. Does the GLEP need to cover how news readers that want to keep > track of whether or not the sysadmin was wearing pants last tuesday > should work too? Nope, which is why news.read shouldn't be specified. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 09:20, Ciaran McCreesh wrote: > On Mon, 12 Dec 2005 09:11:53 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Regardless of what you think about the current plans for multiple > | repository support, the details that readers will need to know wont > | change. > > Incorrect. Right now, readers should ignore news-blah.unread and only > pay attention to news.unread. Readers will have to be updated to deal > with multiple repositories whenever the multiple repositories GLEP is > approved. Incorrect. There needs to be no GLEP regarding multiple repository support in portage. There may need to be a GLEP regarding splitting up the portage tree into separate repositories, but that is nothing to do with the issue I'm talking about. > | > | Even before multiple respositories are properly supported, I > | > | guarantee bugs about support for this in portage overlays. With > | > | the above, we would be able to add that support. Without it, all > | > | we can do is put a big CANTFIX. > | > > | > Overlay is not the same as multiple repository support. > | > | There's no difference as far as readers go. > > Sure there is. there's no metadata/ directory in overlays. Again, why I really don't like this design. You're asking portage to do crap to support external tools without looking to provide compatibilty with future portages. How are you planning to find the metadata directory in the first place? > | Nope, which is why news.read shouldn't be specified. > > news.read is specified because there was demand for it the last time > around. It's staying specified because the reasons given were based > upon convincing use cases rather than random speculation. Can you show a use case that crosses several readers? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 18:30, Duncan wrote: > For example, if repository-id forms a part of the path and we define path > parsing now, then we are effectively defining legal characters for > repository-id now. This is only of concern to portage developers. > That's an entirely different glep, far out of scope and > reaching into other people's territory, limiting how that might be > implemented by defining a portion of the id-scope in an entirely unrelated > glep. No need for a glep as far as portage support goes anymore than Ciaran needs a glep to change or add syntax highlighting in vim. > Given how heated I've seen GLEP discussion get (and I'm not saying that's > /bad/, just a fact), I really can't blame Ciaran for attempting to keep > the scope of the proposal, and therefore the debate, down to exactly what > he's aiming to accomplish, without ending up getting into an entirely > /different/ debate about how he's limiting the future flexibility of the > multiple repo implementation. There doesn't need to be a debate. This whole proposal doesn't care about portage compatibility whatsoever and it's exactly this style of thinking that slows down portage development (which everybody loves to complain about so much). > Once there's a concrete proposal there to work with, then and only then, > he's saying (from my viewpoint), is it appropriate for consideration in > relation to the news proposal. Don't unnecessarily tie the two together, > complicating life for both. Let each be argued on its merits separately, > and when/if multiple repo is actually close enough to deployment that > there's some actual rules to work with, /then/ worry about fixing this to > match. As I said already, there will immediately be a bug asking for overlay support. Portage already supports multiple in a form whether anybody likes it or not. How they are supported and how they will change should be of no concern to the glep. What should be of concern is establishing a robust API between the readers and portage such that future changes won't cause breakage. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 02:16, Ciaran McCreesh wrote: > On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | No need for a glep as far as portage support goes anymore than Ciaran > | needs a glep to change or add syntax highlighting in vim. > > The difference is, Vim syntax scripts are well established, and there > aren't any design issues to solve. Multiple repository support clearly > *isn't* obvious, because the solution you've described is the wrong one. Blah, blah, blah. > | There doesn't need to be a debate. This whole proposal doesn't care > | about portage compatibility whatsoever and it's exactly this style of > | thinking that slows down portage development (which everybody loves > | to complain about so much). > > Sure it does. It cares about the way Portage is currently, and it cares > about any reasonable future Portage changes. Bullshit. > | As I said already, there will immediately be a bug asking for overlay > | support. Portage already supports multiple in a form whether anybody > | likes it or not. How they are supported and how they will change > | should be of no concern to the glep. What should be of concern is > | establishing a robust API between the readers and portage such that > | future changes won't cause breakage. > > Ok, give me a list of every single future enhancement to Portage and > I'll make sure the GLEP will be compatible with them. Without a list of future features, you think the best way to go must be the least agile? As Zac said, all that matters to keep full compatibility on the side of the readers is to add a level of indirection. All your reasoning above falls apart in the face of that simple *logical* request. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP XX: Fix the GLEP process
Abstract The purpose of GLEPs is to coordinate several teams into providing an overall enhancement to Gentoo. However, the GLEP itself is written by a single person rather than a cooperative effort between the teams. Motivation Recent GLEPs have attempted to force things on other teams. This just doesn't work. Specification Rather than coming to the ML with a completed GLEP and then asking for feedback, a GLEP author should look at the teams involved and then select a solicit a member from each team to be responsible for that area of the GLEP. The GLEP author may represent any teams they belong to. Rationale Rather than doing lots of hard work and having it thrown away once it is found to be unacceptable by the teams involved, the teams involved share the hard work and come up with something acceptable to everybody right from the outset. Backwards Compatibility Nothing Reference Implementation Just do it. Copyright Public Domain -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:06, Jason Stubbs wrote: > Abstract > > The purpose of GLEPs is to coordinate several teams into providing an > overall enhancement to Gentoo. However, the GLEP itself is written by a > single person rather than a cooperative effort between the teams. > > > Motivation > > Recent GLEPs have attempted to force things on other teams. This just > doesn't work. > > > Specification > > Rather than coming to the ML with a completed GLEP and then asking for > feedback, a GLEP author should look at the teams involved and then select a > solicit a member from each team to be responsible for that area of the > GLEP. The GLEP author may represent any teams they belong to. A GLEP should list whom has been solicited and provide evidence that each has given their explicit approval of the GLEP. A GLEP without explicit approval of all teams involved cannot receive managerial approval. > Rationale > > Rather than doing lots of hard work and having it thrown away once it is > found to be unacceptable by the teams involved, the teams involved share > the hard work and come up with something acceptable to everybody right from > the outset. > > > Backwards Compatibility > > Nothing > > > Reference Implementation > > Just do it. > > > Copyright > > Public Domain -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:11, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Without a list of future features, you think the best way to go must > | be the least agile? As Zac said, all that matters to keep full > | compatibility on the side of the readers is to add a level of > | indirection. All your reasoning above falls apart in the face of that > | simple *logical* request. > > Every problem can be solved by adding another layer of indirection, > except for the problem of having too many layers of indirection. This > layer you are proposing is not going to do anything useful. It's merely > adding indirection for the sake of it. There's no more need for this > than there is need for a two thousand line XML DTD which allows us to > specify the author's date of birth using an ancient Sumerian calendar. > > Come up with a full specification of how Portage will handle multiple > repositories, and get that specification agreed upon by the people who > will end up having to use it. *Then* come back and ask me to add in > more complexity. I'm not going to over-complicate things to deal with > random hypothetical half-baked speculation. So what are you going to do? I asked already but you didn't answer. How are you going to find $PORTDIR/metadata/news? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | So what are you going to do? I asked already but you didn't answer. > | How are you going to find $PORTDIR/metadata/news? > > At present, by using portageq with a hardcoded suffix. If in the future > Portage introduces new functionality, then clients and the > specification can easily be updated to handle said functionality. And how can that be adapted to work with overlays, completely ignoring the possibility of distinct repositories. Overlays is something that exists already and news support for them is a request that will appear as soon as news support is added. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:24, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:15:43 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | A GLEP should list whom has been solicited and provide evidence that > | each has given their explicit approval of the GLEP. A GLEP without > | explicit approval of all teams involved cannot receive managerial > | approval. > > So... If, hypothetically speaking, someone were to write a GLEP saying > "move developer documentation into the QA group, restructure said > documentation to this new format etc etc", and the QA group were in > favour, and the developer community in general were in favour, and the > council were in favour, and the people proposed by the GLEP to manage > the new documentation were in favour, but the existing owners of the > developer documentation were not, you're saying that it shouldn't be > approved? Yes. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:45, Andrew Muraco wrote: > Jason Stubbs wrote: > >On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: > >>On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <[EMAIL PROTECTED]> > >> > >>wrote: > >>| So what are you going to do? I asked already but you didn't answer. > >>| How are you going to find $PORTDIR/metadata/news? > >> > >>At present, by using portageq with a hardcoded suffix. If in the future > >>Portage introduces new functionality, then clients and the > >>specification can easily be updated to handle said functionality. > > > >And how can that be adapted to work with overlays, completely ignoring the > >possibility of distinct repositories. Overlays is something that exists > >already and news support for them is a request that will appear as soon as > >news support is added. > > Your Point is Moot ... Interesting use of capitals. > because an overlay (at present) is going to be exprimental software, or a repository from a non-English speaking community Gentoo site... > (unsupported offically anyways) and so you _should_ know what risks your > taking, except if your a new non-English-speaking user utilizing such a repository. > this GLEP is to warn you about supported updates/changes which you _need_ to > know about. This GLEP is about getting news regarding a set of ebuilds to the user. Making it only about the Gentoo supported tree serves no purpose. > Why should an overlay need to have news if the user has the consciensely > update and maintain it to begin it. Because they already support package.mask, thirdpartymirrors, eclasses and just about anything else that exists in the supported tree. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:48, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | And how can that be adapted to work with overlays, completely > | ignoring the possibility of distinct repositories. Overlays is > | something that exists already and news support for them is a request > | that will appear as soon as news support is added. > > Overlays don't contain metadata directories There's nothing preventing this. > and don't get synced, As Zac pointed out, esync exists. > so they don't contain news items. Neither of the points above prevent an overlay from containing news items. > Supporting news from multiple sources is something that's tied to supporting > packages from multiple sources, which overlay doesn't permit. Overlays are used for getting packages from multiple sources every day. The only thing preventing them from supporting getting news from multiple sources is your stubborness against adding a single level of indirection - a level of indirection that has absolutely no cost to readers. > Fixing that would require fixing portage to support multiple repositories > rather than using overlay, which is an issue for a different GLEP. I'll say it again. It wouldn't require a GLEP because the changes wouldn't go beyond portage. At least they wouldn't if you'd allow portage to keep its internals internal. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:58, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:39:49 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | > So... If, hypothetically speaking, someone were to write a GLEP > | > saying "move developer documentation into the QA group, restructure > | > said documentation to this new format etc etc", and the QA group > | > were in favour, and the developer community in general were in > | > favour, and the council were in favour, and the people proposed by > | > the GLEP to manage the new documentation were in favour, but the > | > existing owners of the developer documentation were not, you're > | > saying that it shouldn't be approved? > | > | Yes. > > Unworkable. Your proposal would allow a small group of obstinate > developers to hold back progress. The problem here is that the council > isn't acting as a decent last line of quality control when the GLEP > authors fail to do their jobs properly. Your GLEP is trying to solve > the wrong thing... Wrong. I'll expand on the "Yes" now that I've got a few minutes... Actually, I'll turn that into a "No". I misread "the people proposed by the GLEP to manage the new documentation" in my rush to leave for work this morning. The existing owners don't matter to the GLEP. They can continue to maintain the existing documentation if they wish. If you didn't have new people to maintain the new documentation however... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 07:12, Grant Goodyear wrote: > Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST] > > > | As I said already, there will immediately be a bug asking for overlay > > > | support. Portage already supports multiple in a form whether anybody > > > | likes it or not. How they are supported and how they will change > > > | should be of no concern to the glep. What should be of concern is > > > | establishing a robust API between the readers and portage such that > > > | future changes won't cause breakage. > > Wouldn't it suffice for the GLEP to simply have a statement that it will > query portage for a list of repositories, once there's a way to do that, > but until then the default repo will be assumed? Modifications are required to portage anyway. Why postpone it until after several readers are written and force all of them become broken? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 08:54, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Modifications are required to portage anyway. Why postpone it until > | after several readers are written and force all of them become broken? > > Because there isn't a specification saying what the future changes to > Portage will be, so supporting said future changes straight off would > require a massively over-generalised, over-indirected solution. newsdir="$(portageq envvar PORTDIR)/metadata/news" newsdir="$(portageq newsdir gentoo)" Both have one level of indirection. The first has two hard coded elements. The first has one. Where is the massive over-indirection? The second allows future changes. The first does not. Where does the specification come into it? All that would be needed is to allow a user a method to name overlays and it'd be useful straight off the bat. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 09:52, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | newsdir="$(portageq envvar PORTDIR)/metadata/news" > | newsdir="$(portageq newsdir gentoo)" > | > | Both have one level of indirection. The first has two hard coded > | elements. The first has one. Where is the massive over-indirection? > | > | The second allows future changes. The first does not. Where does the > | specification come into it? All that would be needed is to allow a > | user a method to name overlays and it'd be useful straight off the > | bat. > > The former relies upon existing, widely used functionality together > with a well-defined path. The latter has some magic hard-coded name > voodoo (what's a 'gentoo'?) and is still stuck only supporting a single > location. What's a 'PORTDIR'? What's a 'metadata'? Outside of portage, these are also magic name voodoo. But I've grown tired of your imperfect circles. I think your design sucks and you think that my solution to making it not suck is too soon. The solution to that seems simple to me. Rather than have 'package manager' do anything, just have it provide hooks that will allow you to do your thing at the times you want. Good luck with solving the "news in overlays" bug when it comes in. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Wednesday 14 December 2005 06:16, Grant Goodyear wrote: > Jason Stubbs wrote: [Mon Dec 12 2005, 08:06:54PM CST] > > > The purpose of GLEPs is to coordinate several teams into providing an > > overall enhancement to Gentoo. However, the GLEP itself is written by > > a single person rather than a cooperative effort between the teams. > > You know, there's no reason that GLEPs need to be written by a single > person. It's often true, though, that it is a single person's idea, > initially at least. Definitely. Ideas usually are a single person's "eureka" even if it comes through discussion with others. > > Specification > > > > Rather than coming to the ML with a completed GLEP and then asking for > > feedback, a GLEP author should look at the teams involved and then > > select a solicit a member from each team to be responsible for that > > area of the GLEP. The GLEP author may represent any teams they belong > > to. > > Throwing out the initial GLEP amounts to the same thing, in my opinion, > since any interested parties are urged to provide feedback, and ideally > the next revision will include that feedback, either to accept it or > reject it. This is where it is falling down. The assumption is that somebody from each affected team happens to notice the post and have the time to reply before the GLEP goes too far. It also means that the goals and direction of the teams affected have no bearing on the initial revision of the GLEP. With the initial revision of the GLEP setting the direction in which it will head (or fizzle), the GLEP author is essentially handing tasks to various teams (which may conflict with their goals) if the initial revision draws enough support. > > Rationale > > > > Rather than doing lots of hard work and having it thrown away once it > > is found to be unacceptable by the teams involved, the teams involved > > share the hard work and come up with something acceptable to everybody > > right from the outset. > > Yes, of course, GLEP authors should talk to the folks who are likely to > be affected beforehand, but if they fail to do so then the GLEP process > is likely to be rather protracted for that GLEP. I have to admit that I > have no problem with people doing hard work for little gain, if that's > what people want to do. *Shrug* Why go through all that stress? Given GLEP 41, how much effort should infra need to put into defending why the tasks initially set out by the GLEP author are impractical? Is a single email enough? Is a battle with the GLEP author required if the GLEP author disagrees? That's assuming of course that a response was quick enough. It's not only the GLEP authors whom are doing extra unnecessary work. In addition as I missed out the signing off part from the inital post, should council members all be continually polling the lists for disagreement and marking it down in a notebook to be pulled out in time for when the GLEP is put to a vote? Or is it all just down to how convincingly the GLEP author speaks in the meeting where it is voted upon? Because there is no mechanism to ensure otherwise, the latter is inevitably the case. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Friday 16 December 2005 14:57, Alec Warner wrote: > Ciaran McCreesh wrote: > > On Fri, 16 Dec 2005 00:36:54 -0500 Alec Warner <[EMAIL PROTECTED]> > > > > wrote: > > | emerge blar --repo=ciaranmssekritrepo > > | > > | This accomplishes the same thing, except I get to name the repo > > | whatever I wish, and you lose the ability to specify repositories in > > | DEPEND. > > > > ...and it stops you from being able to package.mask things in a given > > repository, > > Ideally there will be per-repo package.mask entries as well, since .mask > files are typically repository-based. Exactly. > > and it stops you from being able to stick to a given > > repository for world entries, and it stops you from being able to use > > /var/lib/portage/world sucks on the whole. The plan is to tag what repo a package came from into the installed package database if I understand correctly. > > it in all those zillion other locations where you can currently use a > > dep atom to do something useful. > > Anything in particular other than "those other useful things"? On Friday 16 December 2005 12:56, Ciaran McCreesh wrote: > DEPEND=">=foo-bar/baz-2.1::ciaranmssekritrepo" > > which would add a restriction that only packages in ciaranmssekritrepo > would be considered. This only works if the repository knows its own > identifier, however... I don't see the need for this. Resolution will the same repository to satisfy a package's dependencies where possible. If you just want to be able to state that a package from one repository needs packages from a different repository, wouldn't something like REPO_URI="mirror://gentoo/repo" suffice just as well without making a mess of the atom syntax? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] pkg_{pre,post}inst misusage
Here's what we have:
app-office/qhacc/qhacc-3.4.ebuild: [ -n "${PF}" ] && rm -rf
/usr/share/doc/${PF}
net-fs/samba/samba-3.0.14a-r2.ebuild: rm -rf
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.14a-r3.ebuild: rm -rf
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20-r1.ebuild:rm -rf
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20a.ebuild: rm -rf
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20b.ebuild: rm -rf
${ROOT}/usr/share/doc/${PF}
net-print/cups/cups-1.1.23-r3.ebuild: rm -fR /usr/share/doc/${PF}
net-print/cups/cups-1.1.23-r4.ebuild: [ -n "${PN}" ] && rm -fR
/usr/share/doc/${PN}-*
net-print/cups/cups-1.1.23-r5.ebuild: [ -n "${PN}" ] && rm -fR
/usr/share/doc/${PN}-*
I'll let others do the yelling.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Friday 23 December 2005 20:19, Stefan Schweizer wrote: > Well, you should know that those are because of portage bugs or some > portage peculiarity, read the corresponding bugs for example for cups > to find out more. Can you point me to a bug? There's no mention in the ChangeLog that I can see nor in the ebuilds themselves... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Friday 23 December 2005 21:39, Harald van Dijk wrote: > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote: > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote: > > > Well, you should know that those are because of portage bugs or some > > > portage peculiarity, read the corresponding bugs for example for cups > > > to find out more. > > > > Can you point me to a bug? There's no mention in the ChangeLog that I can > > see nor in the ebuilds themselves... > > Bug #99375 is mentioned in the changelog for samba. It still doesn't explain why it's necessary. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Friday 23 December 2005 21:39, Harald van Dijk wrote: > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote: > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote: > > > Well, you should know that those are because of portage bugs or some > > > portage peculiarity, read the corresponding bugs for example for cups > > > to find out more. > > > > Can you point me to a bug? There's no mention in the ChangeLog that I can > > see nor in the ebuilds themselves... > > Bug #99375 is mentioned in the changelog for samba. Okay. It appears to be something related to symlinks. Can you show me the bug assigned to portage that reports this and/or shows how to reproduce it? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Friday 23 December 2005 22:13, Harald van Dijk wrote:
> On Fri, Dec 23, 2005 at 10:00:20PM +0900, Jason Stubbs wrote:
> > On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> > > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > > > Well, you should know that those are because of portage bugs or
> > > > > some portage peculiarity, read the corresponding bugs for example
> > > > > for cups to find out more.
> > > >
> > > > Can you point me to a bug? There's no mention in the ChangeLog that I
> > > > can see nor in the ebuilds themselves...
> > >
> > > Bug #99375 is mentioned in the changelog for samba.
> >
> > Okay. It appears to be something related to symlinks. Can you show me the
> > bug assigned to portage that reports this and/or shows how to reproduce
> > it?
>
> Don't know if it's been reported as a portage bug, but this would show
> it:
>
> KEYWORDS="~x86"
> src_install() {
> dodir /test
> dosym /usr/bin /test
> }
>
> When unmerging, portage won't remove /test/bin because its target still
> exists.
Seeing that there's no bug filed for this, discussion can go here; that's no
existance of a portage bug is of itself no reason to put an ugly workaround
in the ebuilds themselves mind you.
Symlinks are handled within portage differently to regular files. Regular
files get an mtime check and are removed if it matches. Symlinks don't get an
mtime check (even thought the mtime is stored) and are only removed if the
symlink's target doesn't exist. Hence, it seems to be this way by design. Why
it's this way? Who knows. It's been that way for longer than anyone can
remember which is why _it's so important that bugs get filed_.
A quick patch makes symlinks handled similarly to regular files and solves the
issue. I'll put it into testing unless anybody can come up with a reason not
to. The case that will be broken by the patch is when two different packages
install the same symlink. PackageA is installed, PackageB is installed,
PackageB is uninstalled -> PackageA is broken. Does this case exist?
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Saturday 24 December 2005 02:11, Zac Medico wrote:
> Harald van Dijk wrote:
> > Don't know if it's been reported as a portage bug, but this would show
> > it:
> >
> > KEYWORDS="~x86"
> > src_install() {
> > dodir /test
> > dosym /usr/bin /test
> > }
> >
> > When unmerging, portage won't remove /test/bin because its target still
> > exists.
>
> That is fixed in portage-2.0.53 (latest stable).
>
> http://bugs.gentoo.org/show_bug.cgi?id=59593
Similar characteristics but slightly different.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Saturday 24 December 2005 02:52, Harald van Dijk wrote: > On Sat, Dec 24, 2005 at 02:22:06AM +0900, Jason Stubbs wrote: > > Symlinks are handled within portage differently to regular files. Regular > > files get an mtime check and are removed if it matches. Symlinks don't > > get an mtime check (even thought the mtime is stored) and are only > > removed if the symlink's target doesn't exist. Hence, it seems to be this > > way by design. Why it's this way? Who knows. It's been that way for > > longer than anyone can remember which is why _it's so important that bugs > > get filed_. > > Honestly, I thought it was supposed to be like that, since > collision-protect also doesn't protect against packages overwriting > each other's symlinks (package A and package B can both create > /dummy -> bin without any problems from portage). As far as portage source goes, it is meant to be like that. But as far as portage source goes, installed package information isn't necessary for dep calculation (including depclean)... Most code has been reviewed and the major issues are known by at least one person, but there is still some code that hasn't suffered a close examination (yet alone reworking) such as the code that the above bug hits. > Do you want a bug report for that? Yes, please. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 02:57, Paul de Vrieze wrote: > On Friday 16 December 2005 18:54, Ciaran McCreesh wrote: > > On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk <[EMAIL PROTECTED]> > > > > wrote: > > | Just one remark: What about making the syntax a bit more familiar to > > | C++ users: > > | > > | ~ DEPENDS="gentoo-foo::foo-bar/baz-2.1" > > > > That was my original thought when I started playing with it. I switched > > to postfix to make it more consistent with the way :slot and [use] > > restrictions work. *shrug* I guess it's down to whether you consider a > > Do those already work then? I'd like to be able to use them. :slot and [use]? Not yet. I'm sure that once they do the shouts will be resounding across the globe such that it would not be possible for you to be unaware of it... ;) -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 03:23, Paul de Vrieze wrote: > On Friday 23 December 2005 19:12, Ciaran McCreesh wrote: > > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]> > > > > wrote: > > | > That was my original thought when I started playing with it. I > > | > switched to postfix to make it more consistent with the way :slot > > | > and [use] restrictions work. *shrug* I guess it's down to whether > > | > you consider a > > | > > | Do those already work then? I'd like to be able to use them. > > > > Not in anything end users should be using. The syntax is pretty much > > decided upon though... > > Glad that they are comming though. Even though I'd probably not hold my > breath. Trolling? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: pkg_{pre,post}inst misusage
On Saturday 24 December 2005 03:43, Duncan wrote: > Jason Stubbs posted <[EMAIL PROTECTED]>, excerpted > > below, on Sat, 24 Dec 2005 02:22:06 +0900: > > A quick patch makes symlinks handled similarly to regular files and > > solves the issue. I'll put it into testing unless anybody can come up > > with a reason not to. The case that will be broken by the patch is when > > two different packages install the same symlink. PackageA is > > installed, PackageB is installed, PackageB is uninstalled -> PackageA is > > broken. Does this case exist? > > Yikes! That's not going to remove /lib or /usr/lib or the like, for us on > amd64, where that's a symlink to lib64, will it? > > equery b /lib > [ Searching for file(s) /lib in *... ] > net-analyzer/macchanger-1.5.0-r1 (/lib) > sys-apps/baselayout-1.12.0_pre12 (/lib) > sys-boot/grub-0.97 (/lib) > sys-devel/gcc-4.0.2-r1 (/lib) > sys-devel/gcc-3.4.4-r1 (/lib) > sys-fs/device-mapper-1.01.05 (/lib) > sys-fs/lvm2-2.01.14 (/lib) > sys-fs/udev-078 (/lib) > sys-libs/glibc-2.3.6 (/lib) > > There's a similar, longer list, for /usr/lib. Obviously, not all of > those will own it as a symlink, but it is one, and if removing one happens > to remove the symlink... I'm not familiar with equery so I don't know what this output means. By the look of it, it is only a list of packages that own stuff in that directory. > Also consider the effect where a former dir is now a symlink or a former > symlink is now a dir. The recent xorg directory moves come to mind. With the patch I've done, recorded symlinks will continue to be ignored if the target is not a symlink. > You are /sure/ the new code won't screw anything of that sort up, right? > Maybe that's the reason nobody seems to have been around to know about. > It just sounds like it /could/ be dangerous to me. For some reason, I > don't like the idea of something that could hose a system that badly! =8^\ *Please* don't tell me you run ~arch. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Saturday 24 December 2005 03:42, Thomas de Grenier de Latour wrote: > On Sat, 24 Dec 2005 02:22:06 +0900 > > Jason Stubbs <[EMAIL PROTECTED]> wrote: > > PackageA is installed, PackageB is installed, PackageB is > > uninstalled -> PackageA is broken. Does this case exist? > > Found two on my system: > > * "/usr/lib/X11/app-defaults -> /etc/X11/app-defaults" is > installed by several X11 apps (media-gfx/xfig, x11-misc/seyon, > x11-misc/xvkbd, and i would not be surprised there are others) This looks like something that a lower level X ebuild should be installing. The problem here is that there's also a bit of funny business going on when portage encounters a merge of some filetype being blocked by a different filetype. In the above case, if some X11 package installs the /usr/lib/X11/app-defaults symlink and all other apps install to /etc/X11/app-defaults then everything should be fine. > * "/usr/share/cups/model/foomatic-ppds -> /usr/share/ppd" is > installed by both net-print/foomatic-db and net-print/hplip. Again, given the name of the symlink, net-print/hplip should probably be installing directly to /usr/share/ppd. > Maybe this particular packages could be hacked to avoid need for > the symlinks (or the symlinks should be installed only by some > lower level, depended-on, packages?), but anyway it would be hard > to do a strict sanity check of the whole tree. And letting that to > "collision-protect" feature doesn't sound really like a short term > solution neither. So, basically, i don't see how you could safely > change this portage behavior atm (although i agree it would be a > good thing once done). Yep, it seems that changing the behaviour will lead to some breakage. However repoman is definately not capable of handling this sort of stuff. Also, none of the breakage (that you've revealed here at least) is that bad. Putting the relevant collision-protect changes into ~arch and following up with the actual unmerge changes should lead to minimal disruption on the user's side. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 05:45, Spider (DmD Lj) wrote: > On Sat, 2005-12-24 at 03:37 +0900, Jason Stubbs wrote: > > On Saturday 24 December 2005 03:23, Paul de Vrieze wrote: > > > On Friday 23 December 2005 19:12, Ciaran McCreesh wrote: > > > > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]> > > > > > > > > | Do those already work then? I'd like to be able to use them. > > > > > > > > Not in anything end users should be using. The syntax is pretty much > > > > decided upon though... > > > > > > Glad that they are comming though. Even though I'd probably not hold my > > > breath. > > > > Trolling? > > Erm.. No, I don't think he is. We've been asking / waiting for the > [use] syntax to appear since before you joined the project. It's been on > "the list" for so long that many of us have given up... ; ) Yep, bug 2272. > I don't think its trolling when we've been let down on it in the past, > had it postponed to "the great redesign" ( project baghira, I think, > too) And so on. "Even though I'd probably not hold my breath"? It's something that many people want but most are not evening willing to attempt implementing it. What was the purpose of that comment? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 10:25, Ciaran McCreesh wrote: > On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <[EMAIL PROTECTED]> > > wrote: > | kde-libs/kde:3 > | ^^^ need any kde, with slotting enabled. > | > | kde-libs/kde:3,4 > | ^^^ need any kde, slotting 3 or 4. I'd prefer to not have this last one. It can be done as "|| ( kde-libs/kde:3 kde-libs/kde:4 )" whereas all other atom constructs are already at their most minimalistic form. > Will foo-bar/baz:3* or foo-bar/baz:3.* work? SLOT is currently an arbitrary string (without spaces) so general matching of "*" might be useful. Of course, there's no restriction of not using "*" in SLOTs at the moment either... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 12:58, Ciaran McCreesh wrote: > On Sat, 24 Dec 2005 12:50:33 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | SLOT is currently an arbitrary string (without spaces) so general > | matching of "*" might be useful. Of course, there's no restriction of > | not using "*" in SLOTs at the moment either... > > *shrug* SLOT will have to be tightened up anyway. Otherwise > SLOT="[foo]" will cause terrible confusion. Heh. Yep, that's another one. Checking with a quick script, it seems that there are 478 unique SLOTs and the regex [a-zA-Z0-9\._\-]* matches them all. Perhaps it would be worthwhile locking it down to those characters in repoman in preparation? Anybody see a need for characters beyond those? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support
On Sunday 25 December 2005 02:33, Ciaran McCreesh wrote: > On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <[EMAIL PROTECTED]> > > wrote: > | It's really pretty simple- get off your butt and chip in if you want > | it, else you're on _our_ timeline (eg, we implement it when we deem > | it sane/ready to go). > > Is Portage development done to support the needs of those of us who > provide the tree, or is the tree expected to be restricted to whatever > Portage developers feel like implementing? Neither. At least for myself, portage development is done to prioritized according to what I see as the needs of users. Needs of "those of us who provide the tree" are prioritized by how much benefit will be translated to end users combined with how much work will be required. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 08:14, Brian Harring wrote:
> On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
> > Currently there are quite a few ebuilds in the tree that execute dodoc
> > or dohtml for files that do not exist. I think it would be nice to have
> > ebuilds die if this is the case. To not break current ebuilds this would
> > only happen with FEATURES="stricter". This is what I currently do in my
> > bashrc. Obviously when integreted to portage one can use helper
> > functions like hasq which are not available in bashrc.
> >
> >
> > if [[ "${FEATURES/stricter}" != "${FEATURES}" ]]; then
> >
> > _makefail() {
> > bin="/usr/lib/portage/bin/${1}"
> > shift 1
> > "${bin}" "[EMAIL PROTECTED]" || die "${bin} [EMAIL PROTECTED] failed"
> > }
> >
> > dodoc() { _makefail ${FUNCNAME} "[EMAIL PROTECTED]"; }
> > dohtml() { _makefail ${FUNCNAME} "[EMAIL PROTECTED]"; }
>
> Seems like more of a -dev discussion imo, since they're the ones
> affected by it (for us it's just an api change).
As a side note, dodoc didn't return non-zero when specified files don't exist
up until a month or two ago. dohtml was updated yesterday. Hence, up until
now the above was not possible.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 20:01, Jakub Moc wrote: > >> Currently there are quite a few ebuilds in the tree that execute dodoc > >> or dohtml for files that do not exist. I think it would be nice to have > >> ebuilds die if this is the case. To not break current ebuilds this would > >> only happen with FEATURES="stricter". > > Sigh... There are already bugs flowing in for TEXTRELs/executable stacks > checks implemented in recent portage versions. Some of these bugs are > completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc. > etc. Sigh... None of these issues have made there way to dev-portage. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 12:08, Brian Harring wrote: > On Tue, Dec 27, 2005 at 03:54:38AM +0100, Carsten Lohrke wrote: > > On Tuesday 27 December 2005 03:40, Brian Harring wrote: > > > The version of digikam being merged requires slot=3.5- it should be > > > depending on libk* slot=3.5, also, no? > > > > No! It (and also its dependencies) can be built against each 3.x slot. > > > > > As long as the information is represented dependency wise, portage > > > should be able to handle it fine. Just need to have that info there. > > > > It can't be handled dependency wise, because what is interesting is > > against which KDE version the relevant ebuilds are actually installed. > > So note the comment in the email you are responding to about locking > down the used dep/rdeps for an install. > > Via that, could lock down the slot it was compiled against. Bit more > to it then that, but the concerns your raising *again* are not > use/slot based, your pointing at other portage faults (thus please > seperate those concerns from use/slot). I may be missing something, but I can't see how this will resolve Carsten's issue. From what I can tell, the ebuilds would be laid out something like: digikam:DEPEND="|| ( kdelibs:3.5 kdelibs:3.4 ) libkipi libkexif" libkipi:DEPEND="|| ( kdelibs:3.5 kdelibs:3.4 )" libkexif:DEPEND="|| ( kdelibs:3.5 kdelibs:3.4 )" If all three of those packages were first built against kdelibs:3.4 and then kdelibs:3.5 became available then rebuilding any one of them without rebuilding the others will break digikam. I can't see how it's directly represented in the metadata unless you want to overload the meaning of SLOT. If overloading, dependencies would be flattened (meaning "|| ( kdelibs:3.5 kdelibs:3.4 )" would have became "kdelibs:3.4" for the original install) within the installed package database but there's also there's the implication that only one slot of a package be allowed in a connected set of nodes. Is that what you're getting at? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 22:45, Carsten Lohrke wrote: > On Tuesday 27 December 2005 14:00, Jason Stubbs wrote: > > If all three of those packages were first built against kdelibs:3.4 and > > then kdelibs:3.5 became available then rebuilding any one of them without > > rebuilding the others will break digikam. I can't see how it's directly > > represented in the metadata unless you want to overload the meaning of > > SLOT. > > It's not possible to represent that via dependencies. What is needed is > some sort of introspection which relevant ebuild is built against which KDE > version and if those _installed_ ebuild:kdever combinations match the one > the _actual_ ebuild to emerge. Do you mind reading and replying to the second paragraph (which happens to be the only new information I brought to this thread). Underlining words to emphasize a point to me that I've opened by agreeing is really not necessary. > But you're right about the overloading of the meaning of slots, because > that's happening right now. Slots are used to install several versions of a > package side by side. The idea Ciaranm and Brian are proposing to lock > ebuilds depending on slotted packages down to a single slot is the > redefinition. And once again: This doesn't match reality. You've misunderstand what is meant by "locking ebuild dependencies". I gave you a definition in my second paragraph. Please have a re-read. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
> On Monday 26 December 2005 21:28, Ciaran McCreesh wrote: > > On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke <[EMAIL PROTECTED]> > > Well, any library that changes ABI should use a different SLOT for each > > revision. So SLOT depends should be able to replace the need for = and > > ~ and < and <= dependencies entirely. Which is a good thing, since > > those atoms make dependency resolution a general-case unsolvable > > problem. There's a lot of "should"s that are "aren't"s in there, but in principle that is a very elegant idea. On Wednesday 28 December 2005 00:48, Paul de Vrieze wrote: > Well, it shouldn't be unsolvable. Choosing can be done with the following > process: > > - Get the list of packages with the requested name. > - Sort the list from the newest version, to the oldest. > - Iterate over the packages: > - Apply all restrictions on the package (including exclusions). If the > package satisfies all, test it's dependencies recursively. ^^^ This step fails. When the set of restrictions cannot be resolved, you need to backtrack and try a lesser version of a previous package hence the set of "all restrictions" is constantly in flux. > - If all dependencies match, this package matches the dependency. > Continue with the next depend atom. > - If no match, iterate the next package. If backtracking was all there was to it, it could be done very quickly of course. However, it's essentially a brute force method; I'm not very good with O notation but I think it's O(n^n). I've got an algorithm in my head that'll do it but it goes into an infinite loop in the cases that Carsten mentioned. That's why things are taking so long. I should really write it down... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote: > On Tue, 2005-12-27 at 19:06 +, Ciaran McCreesh wrote: > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <[EMAIL PROTECTED]> > > > > wrote: > > | On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote: > > | > Nnnope. If you modify an eclass it forces a cache regen for packages > > | > using said eclass (except possibly if you're using an overlay, but > > | > that's a separate issue...). > > | > > | You're trying to solve something which is already solved, but this > > | has nothing to do with our problem. The question is not listen the > > | possible valid KDE versions or a change of the eclass, but the need > > | to know actual used KDE version. You'd need to call e.g. kde-config > > | to get it. And this breaks caching. > > > > So you RDEPEND upon the version of KDE against which you were built, > > and use the || ( ) flattening feature that's already been proposed. > > Thats actually viable. For -installed- ebuilds, we simply unpack all > RDEPEND logic, remove all use flags ( stored, but the use logic is > removed from the RDEPEND since its already resolved, doesn't need to be > there. The binary is static already ) > > Then check vs. the installed SLOT of all RDEPEND packages, and lock our > current deptree to the package of that SLOT... I suggested this last Tuesday.. > I can smell sooo much breakage from this solution. Even though it could > work : ) I'm not sure to interpret this as "yet another snide remark" or not so I'll give you the benefit of the doubt and assume you're referring to sets of ebuilds that require several slots. Before implementing the above, the tree will be checked for any cases where the above idea will fail. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Friday 30 December 2005 21:17, Spider (DmD Lj) wrote: > On Fri, 2005-12-30 at 10:35 +0900, Jason Stubbs wrote: > > On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote: > > > On Tue, 2005-12-27 at 19:06 +, Ciaran McCreesh wrote: > > > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <[EMAIL PROTECTED]> > > > > > > Thats actually viable. For -installed- ebuilds, we simply unpack all > > > RDEPEND logic, remove all use flags ( stored, but the use logic is > > > removed from the RDEPEND since its already resolved, doesn't need to be > > > there. The binary is static already ) > > > > > > Then check vs. the installed SLOT of all RDEPEND packages, and lock our > > > current deptree to the package of that SLOT... > > > > I suggested this last Tuesday.. > > No, what you suggested was that for the case of when you depend on a > SLOT, then the tree is flattened. My point was for the generic case : > > DEPEND=">=kde-base/kdelibs-3.0" (as many ebuilds look today) > > is then expanded to the current matching SLOT of kdelibs, so even if > there -wasn't- a SLOT requirement beforehand, there is one afterwards. Okay, I misinterpreted. Anyway, it looks like neither of our ideas will work: app-text/docbook-sgml/docbook-sgml-1.0.ebuild: RDEPEND="app-text/sgml-common app-text/openjade >=app-text/docbook-dsssl-stylesheets-1.64 >=app-text/docbook-sgml-utils-0.6.6 ~app-text/docbook-sgml-dtd-3.0 ~app-text/docbook-sgml-dtd-3.1 ~app-text/docbook-sgml-dtd-4.0 ~app-text/docbook-sgml-dtd-4.1" docbook-sgml-dtd-3.0-r3.ebuild:SLOT="3.0" docbook-sgml-dtd-3.1-r3.ebuild:SLOT="3.1" docbook-sgml-dtd-4.0-r3.ebuild:SLOT="4.0" docbook-sgml-dtd-4.1-r3.ebuild:SLOT="4.1" -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Friday 30 December 2005 22:13, Spider (DmD Lj) wrote: > it would block against "requirement of same package with different SLOT. > > However, since the ~ atoms are explicit and separate ( this depend tree > could as well be called : > app-text/docbook-sgml-dtd:3.0 > app-text/docbook-sgml-dtd:3.1 > app-text/docbook-sgml-dtd:4.0 > app-text/docbook-sgml-dtd:4.1 > > Which, for some reason, should be supported : ) > > Either by casing out appearances where multiple SLOTs are depended on by > -one- package, or by saying that ~ is special-cased due to its stricter > limitations, which would make it pass by the SLOT check. > > ( no, its not an elegant solution, but it might work ;) Inelegant solutions gets us no further than where we are now. ;) A still inelegant solution, but one that I could live with, is to leave SLOT handling as it is now and to take Brian's syntax of key:slot,slot using it specifically for the case where a set of ebuilds must all use the same slot. Hence, rather than digikam and friends having "|| ( kdelibs:3.4 kdelibs:3.5 )" each would have just "kdelibs:3.4,3.5". It still sounds messy given the current redesign of atom handling, but it would seem to offer a better chance of not being bug-ridden... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SuperH (sh) KEYWORD spam
On Saturday 31 December 2005 18:57, Mike Frysinger wrote: > i'm injecting sh KEYWORDS as quickly as my lantank can emerge ... So that's one package every two weeks then? ;) -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [POLL] portage-2.1 USE flag ordering
Hi all, I've started a poll on the specific question of USE flag ordering in portage-2.1_pre3 at http://forums.gentoo.org/viewtopic-t-426033.html The result of the poll will pretty much dictate what will happen in the next release so if you'd like to go over and cast your vote... :) There's also a more general poll at http://forums.gentoo.org/viewtopic-t-423275.html which also allows further discussion if anybody is wanting to offer detailed opinions. Thanks in advance. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 15:53, Ciaran McCreesh wrote: > On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz > <[EMAIL PROTECTED]> wrote: > | > * The clean solution is the solution originally proposed to this > | > list, and the reason we are using new style virtuals. > | > | No, this is wrong. The reason we are using new style virtuals is so we > | could have a versioning in what provides virtual/x11. Namely, 6.8 or > | older. > > Uh, given that you can do that with old style virtuals, methinks that > isn't the case... Only by modifying every ebuild that has a virtual/x11 dependency. The atom "virtual/x11" cannot be limited to specific versions on its own with old style virtuals. > | > * You are doing this because you believe that it is better to get > | > every package ported over extremely quickly rather than having the > | > odd package with extra unnecessary listed dependencies, and you do > | > not consider the impact upon our users to be relevant. > | > | I consider ~arch users to have agreed to help test and fix new things. > | This is included. I would not do the same thing to our stable tree, or > | if we only had a stable tree. > | > | Yes, I do think it is better to have a quick solution and let some of > | our ~arch users see a couple of blocks, for which they will file bugs. > | Then these bugs will be fixed within a day, and those users will again > | have working systems. > > ...or you could do things as originally planned, and have no > non-working systems at all and the only consequences for end users will > be a small number of extra packages (that they previously had installed > anyway as part of hugeass X) being pulled in. The premise for not doing this is that packages will never be fixed, right? Why not make the modular X provide virtual/x11 and just institute a policy that no new packages can go into stable with a virtual/x11 dependency? It could even be easily enforcable if necessary. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 16:19, Donnie Berkholz wrote: > Jason Stubbs wrote: > > Only by modifying every ebuild that has a virtual/x11 dependency. The atom > > "virtual/x11" cannot be limited to specific versions on its own with old > > style virtuals. > > Is that so? I guess this must be wrong, then: > > /usr/portage/profiles/base/virtuals:# Only have this for >=pam-0.78, as > we want to make use of the 'include' > /usr/portage/profiles/base/virtuals:virtual/pam > >=sys-libs/pam-0.78 Yep, portage simply removes the >= and 0.78 parts and makes all versions of sys-libs/pam a provider of virtual/pam. Why there is no warning I don't know. > > The premise for not doing this is that packages will never be fixed, > > right? Why not make the modular X provide virtual/x11 and just institute a > > policy that no new packages can go into stable with a virtual/x11 > > dependency? It could even be easily enforcable if necessary. > > How does that fix the stale, unmaintained here and upstream apps that > are in stable now and have no ~arch ebuilds? It wouldn't, but at least there'd be fewer packages to deal with in the final cleanup. It was just an innocent question though; as far as I can tell, emerging any application (ported or not) on a clean system will not break even after modular X is unmasked. It's a fine line between whether packages "needlessly" not working together due to incompatible (deep) dependencies is considered breakage or not though... /me steps away from the flames for fear of getting burned. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 16:40, Donnie Berkholz wrote: > Ciaran McCreesh wrote: > > On Wed, 25 Jan 2006 16:08:07 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > > | The premise for not doing this is that packages will never be fixed, > > | right? Why not make the modular X provide virtual/x11 and just > > | institute a policy that no new packages can go into stable with a > > | virtual/x11 dependency? It could even be easily enforcable if > > | necessary. > > > > Much more sensible. > > I've thought some about this. It would be acceptable to me for > virtual/x11 to provide modular X deps, if we also instituted a repoman > death upon any attempt to commit to a directory for which the best > visible package is broken. > > This will accomplish the goal of discovering completely unmaintained > packages but will fail in the goal of discovering which packages nobody > uses. They'll still continue to rot in the tree, unmaintained, unused > and taking up space in everybody's syncs. > > How's that sound? I'm not exactly sure what you mean by "broken" in the first paragraph nor how a check can help with unmaintained (=no commits, no?) packages, but if a repoman check will hasten package porting while smoothing the users' ride, I'm personally all for it. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 17:43, Donnie Berkholz wrote: > Jason Stubbs wrote: > > I'm not exactly sure what you mean by "broken" in the first paragraph nor > > how a check can help with unmaintained (=no commits, no?) packages, but if > > a repoman check will hasten package porting while smoothing the users' > > ride, I'm personally all for it. > > By "broken" I mean unported. In other words, directly depending on > either virtual/x11 or x11-base/xorg-x11. The check will help discover > unmaintained packages by not allowing people to do flyby fixes without > also fixing this. > > What can I do to speed up the process of getting this into a 2.1 > release? Keep in mind my python is beyond bad. Perhaps not so easy. What specific states need to be checked for to regard a package as broken? Depending on "x11-base/xorg-x11" is one. Depending on "virtual/x11" seems to be valid looking at the porting guide though. Would considering a package broken if it contains "virtual/x11" where the token immediately preceding the surrounding brackets is not "||" be correct? DEPEND="x11-base/xorg-x11" # wrong DEPEND="virtual/x11"# wrong DEPEND="|| ( x11? ( virtual/x11 ) )"# wrong DEPEND="|| ( misc/atoms virtual/x11 )" # right There's a small possibility that broken packages will be missed by this, but is there any chance that valid packages will be incorrectly flagged? If this gets a go-ahead, it'll be easy enough to get in for the next release (which is likely this coming Saturday). -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote: > Jason Stubbs wrote: > > DEPEND="x11-base/xorg-x11" # wrong > > DEPEND="virtual/x11"# wrong > > DEPEND="|| ( x11? ( virtual/x11 ) )"# wrong > > DEPEND="|| ( misc/atoms virtual/x11 )" # right > > > > There's a small possibility that broken packages will be missed by this, > > but is there any chance that valid packages will be incorrectly flagged? > > If this gets a go-ahead, it'll be easy enough to get in for the next > > release (which is likely this coming Saturday). > > It sounds right. There should be no valid instance of virtual/x11 that > is not within an || dep. I've implemented and tested the check locally but haven't committed it yet. Repoman isn't really structured to allow for tests against a set of ebuilds so the checks are done on every version. There is also definitely one false positive (virtual/x11-6.8) so, for this and the fact that every version is tested, it would probably better to just make it a warning. Thoughts? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 20:46, Brian Harring wrote: > On Wed, Jan 25, 2006 at 08:27:22PM +0900, Jason Stubbs wrote: > > On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote: > > > Jason Stubbs wrote: > > > > DEPEND="x11-base/xorg-x11" # wrong > > > > DEPEND="virtual/x11"# wrong > > > > DEPEND="|| ( x11? ( virtual/x11 ) )"# wrong > > > > DEPEND="|| ( misc/atoms virtual/x11 )" # right > > > > > > > > There's a small possibility that broken packages will be missed by > > > > this, but is there any chance that valid packages will be incorrectly > > > > flagged? If this gets a go-ahead, it'll be easy enough to get in for > > > > the next release (which is likely this coming Saturday). > > > > > > It sounds right. There should be no valid instance of virtual/x11 that > > > is not within an || dep. > > > > I've implemented and tested the check locally but haven't committed it > > yet. Repoman isn't really structured to allow for tests against a set of > > ebuilds so the checks are done on every version. There is also definitely > > one false positive (virtual/x11-6.8) so, for this and the fact that every > > version is tested, it would probably better to just make it a warning. > > Thoughts? > > Curious about the mechanism you're using for this... a hardcoded set > of atoms in repoman doesn't sound very nice to me ;) Get off it. There's no other way to do it given repoman's state and the requirements. If you'd like to make repoman pluggable, convert all the current checks to plugins and then make a new plugin for this one and do it all by this weekend, be my guest. :P Besides, what's wrong with hardcoded atoms in repoman anyway? Repoman doesn't have to stand the test of time. Conversely, it should represent checks for whatever issues are present in the tree at the time of its release. http://dev.gentoo.org/~jstubbs/x11_deprecation_check.diff -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 21:47, Brian Harring wrote: > On Wed, Jan 25, 2006 at 09:18:28PM +0900, Jason Stubbs wrote: > > There's no other way to do it given repoman's state and the requirements. > > I was talking long term. One time kludges suck (but occur), would like to > see something a bit less short sighted for this though- variants of this > request will come up sooner or later (most likely in the form of can we > warn/error on new commits of deprecated deps). > > Might be wise discussing potential solutions for it. This is off-topic now. > > If you'd like to make repoman pluggable, convert all the current checks to > > plugins and then make a new plugin for this one and do it all by this > > weekend, be my guest. :P > > Harass antarus, he's been working on integrating swegeners rewrite of > repoman checks (plugins effectively) into mainline repoman. :P > > Besides, a massive change to repoman with 3 days to go is a no go anyways > (kind of limited the choices there) ;) Would 10 days or 17 days really be any different? > > Besides, what's wrong with hardcoded atoms in repoman anyway? > > portage (by extension repoman) is used beyond gentoo. Not everyone may be > at the same step as we are for mod x. End result of hardcoding gentoo > specific crap into repoman is that you force derivatives of gentoo > (vidalinux or genux fex) to start hacking up portage source to remove said > hardcoding. > > Portage exists beyond gentoo; thus gentoo specific hacks should be avoided > when possible. Such as warning/failing on: * the server's repository path is "/space/cvsroot" * any extensions to metadata.xml * larger-than-20k-files * not being copyrighted to Gentoo Foundation * not being distributed under GPLv2 There's probably others but all of those things are Gentoo specific and cause no less trouble than what a virtual/x11 check might cause. > So... long term? Refactor/rewrite/modularize/blah repoman. In the mean time, make do with what we have and let Gentoo derivatives do the same. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Thursday 26 January 2006 16:08, Donnie Berkholz wrote: > It prints about 10X of crap like this: > > virtual/libc !virtual/xemacs berkdb? ( =sys-libs/db-1* > >=sys-libs/gdbm-1.8.0 ) >=sys-libs/zlib-1.1.4 >=dev-libs/openssl-0.9.6 > >=media-libs/audiofile-0.2.3 gpm? ( >=sys-libs/gpm-1.19.6 ) postgres? ( > >=dev-db/postgresql-7.2 ) ldap? ( net-nds/openldap ) nas? ( > media-libs/nas ) dnd? ( x11-libs/dnd ) X? ( virtual/x11 ) motif? ( > >=x11-libs/openmotif-2.1.30 ) athena? ( virtual/x11 ) Xaw3d? ( > x11-libs/Xaw3d ) neXt? ( x11-libs/neXtaw ) xface? ( media-libs/compface > ) tiff? ( media-libs/tiff ) png? ( =media-libs/libpng-1.2* ) jpeg? ( > media-libs/jpeg ) canna? ( app-i18n/canna ) !amd64? ( freewnn? ( > app-i18n/freewnn ) ) >=sys-libs/ncurses-5.2 !bootstrap? ( sys-devel/patch ) This was testing/debugging left in by mistake. > Then doesn't print the one line saying > "app-editors/xemacs/xemacs-21.4.15-r3.ebuild: RDEPEND has deprecated x11 > dependencies" without a "full" listing? That doesn't make sense -- if it > has to be one way or the other, it should be the reverse. That's a standard repoman thing. Details are only printed if there are less than 12 occurrences of a specific warning unless "repoman full" is run. Not sure why it wasn't being displayed if there was only one occurrence. The patch now has the debugging output and x11-base/xorg-x11 check removed. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Thursday 26 January 2006 20:56, Brian Harring wrote: > Patch misses on > || ( virtual/x11 ) A theoretical case, but if you want to cover it... > || ( x86? ( virtual/x11 ) b ) > via the latter, kind of guranteed it's going to miss on It's not a "miss" per se as much as other dependency checks that aren't performed are a miss when there is invalid syntax - which prevents a commit anyway. If you make "b" a proper atom that specifies a category it'll be picked up. > || ( x86? ( valid-dep ) virtual/x11 ) There is no way that I can see around this without highly increasing the possibility of false positives. Are you planning to treat arch flags separately? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Thursday 26 January 2006 22:09, Jason Stubbs wrote: > There is no way that I can see around this without highly increasing the > possibility of false positives. I extracted a list of cps from repoman, modified your script to check all cpvs (rather than only the best) and compared that with repoman's cps. The attached result.diff file prefixes repoman-only detection with a "-" and the separate tool-only detection with a "+". Your fixes to seem to producee many false positives and introduce some false negatives as well. There may be true positives that I'm missing but I couldn't find one picking a few cases at random. Either way, it doesn't matter if there a few false negatives as it's only meant to be an aid. False positives on the other hand are unacceptable. -- Jason Stubbs +app-accessibility/gok -app-cdr/nero +app-editors/nvu +app-editors/vim +app-editors/zoinks -app-emulation/cedega +app-emulation/dosemu -app-emulation/pearpc -app-emulation/point2play +app-emulation/vice -app-emulation/vmware-workstation +app-emulation/wine -app-emulation/winex-transgaming +app-i18n/kinput2 -app-i18n/uim-svn +app-misc/beagle +app-misc/oneko -app-misc/tkpasman -app-office/mozilla-sunbird-bin +app-office/magicpoint +app-office/openoffice +app-office/openoffice-ximian -app-pda/qtopia-desktop-bin -app-portage/portagemaster +app-portage/test +app-shells/fish +app-text/cstetex +app-text/gv +app-text/ptex -dev-embedded/ponyprog +dev-games/ode -dev-java/gnu-classpath +dev-java/blackdown-jre -dev-lang/smalltalkx +dev-lang/swi-prolog-lite -dev-lisp/mit-scheme +dev-util/insight -dev-util/weka -games-action/phobiaiii +games-action/tuxkart +games-action/xpilot +games-action/xpilot-ng -games-arcade/emergence-bin +games-arcade/koules -games-arcade/mtp-target-bin +games-arcade/ppracer +games-arcade/xgalaga +games-arcade/xjump +games-board/cgoban -games-emulation/boycott-advance-sdl -games-emulation/dgen-sdl -games-emulation/hugo -games-emulation/kigb -games-emulation/mastergear-bin +games-emulation/snes9x -games-emulation/vgba -games-fps/fuhquake-bin -games-fps/postal2mpdemo -games-fps/unreal -games-fps/vendetta-online-bin -games-puzzle/pauker -games-puzzle/triptych-demo +games-puzzle/xwelltris +games-roguelike/nethack -games-server/WarpPipe +games-server/crossfire-server +games-sports/miniracer +games-sports/ultimatestunts +games-strategy/freeciv +gnome-base/control-center +gnome-base/nautilus -mail-client/ciphire-mail -mail-client/mozilla-thunderbird-bin +kde-base/kdesktop +mail-client/mozilla-thunderbird +media-fonts/x11fonts-jmk +media-gfx/fbida -media-gfx/povtree -media-libs/devil +media-libs/gd +media-libs/giblib +media-libs/glide-v3 -media-libs/hamlib +media-libs/libcaca +media-libs/libmpeg2 +media-libs/libquicktime +media-libs/plib +media-libs/urt -media-libs/xpm +media-plugins/libvisual-plugins -media-radio/tucnak1 -media-radio/xconvers -media-radio/xdx -media-radio/xlog -media-sound/mup +media-tv/kdetv +media-tv/xdtv +media-video/motioneye +media-video/mplayer +media-video/xanim -media-video/yanc +net-analyzer/sara -net-im/ymessenger +net-libs/gecko-sdk -net-misc/ltsp -net-misc/mindterm -net-misc/nxserver-business -net-misc/nxserver-enterprise -net-misc/nxserver-personal +net-misc/vnc -net-misc/xsmbrowser -net-nntp/bnr2 -net-p2p/phex +net-print/xpp +net-www/gnash +net-www/mplayerplug-in +sci-chemistry/ghemical +sci-chemistry/gopenmol -sci-chemistry/nmrpipe -sci-chemistry/nmrview +sci-chemistry/rasmol +sci-chemistry/viewmol +sci-electronics/spice +sci-libs/libgdgeda +sci-misc/boinc +sys-apps/pcmcia-cs +sys-devel/gcc +www-client/elinks -www-client/mozilla-bin -www-client/mozilla-firefox-bin +www-client/mozilla +www-client/mozilla-firefox -www-client/opera +x11-libs/Xaw3d +x11-libs/libdockapp +x11-libs/libxsettings-client +x11-libs/qt +x11-libs/startup-notification +x11-misc/3ddesktop +x11-misc/accessx +x11-misc/autocutsel -x11-misc/commonbox-utils +x11-misc/chgres +x11-misc/dclock +x11-misc/electricsheep +x11-misc/fireflies +x11-misc/fspanel +x11-misc/fxred +x11-misc/hsetroot +x11-misc/imwheel +x11-misc/mixer_app +x11-misc/numlockx +x11-misc/obpager +x11-misc/pogo +x11-misc/seyon +x11-misc/skippy +x11-misc/temperature-app +x11-misc/transset +x11-misc/vnc2swf +x11-misc/wayv +x11-misc/x2vnc +x11-misc/x2x +x11-misc/xautomation +x11-misc/xbatt +x11-misc/xbattbar +x11-misc/xcalendar +x11-misc/xcb +x11-misc/xclip +x11-misc/xcompmgr +x11-misc/xcut +x11-misc/xdaf +x11-misc/xdaliclock +x11-misc/xearth +x11-misc/xfishtank +x11-misc/xfm +x11-misc/xhkeys +x11-misc/xinput +x11-misc/xkbd +x11-misc/xkeycaps +x11-misc/xmountains +x11-misc/xnc +x11-misc/xnview +x11-misc/xplanet +x11-misc/xrestop +x11-misc/xrmap +x11-misc/xsetleds +x11-misc/xsimpsons +x11-misc/xsnap +x11-misc/xsnow +x11-misc/xstroke +x11-misc/xteddy +x11-misc/xtoolwait +x11-misc/xtrlock +x11-misc/xvidcap +x11-misc/xvkbd +x11-misc/xwit +x11-misc/xwrits +x11-misc/xxkb +x11-plugins/allin1 +x11-plugins/cputnik +x11-pl
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 14:17, Diego 'Flameeyes' Pettenò wrote: > [ebuild R ] media-tv/kdetv-0.8.8-r1 USE="-arts -debug -lirc -opengl > -xinerama -zvbi" LINGUAS="it% -bg% -br% -ca% -cs% -cy% -da% -de% -el% > -en_GB% -es% -et% -fi% -fr% -ga% -gl% -hu% -is% -lt% -mt% -nb% -nl% -pa% > -pl% -pt% -pt_BR% -ro% -ru% -rw% -sr% [EMAIL PROTECTED] -sv% -ta% -tr% > -zh_CN%" 0 kB This would only be on the first installation. The "%" symbol indicates that the flags have been added. On the second run it would become: > [ebuild R ] media-tv/kdetv-0.8.8-r1 USE="-arts -debug -lirc -opengl > -xinerama -zvbi" LINGUAS="it -bg -br -ca -cs -cy -da -de -el -en_GB -es -et > -fi -fr -ga -gl -hu -is -lt -mt -nb -nl -pa -pl -pt -pt_BR -ro -ru -rw -sr > [EMAIL PROTECTED] -sv -ta -tr -zh_CN" 0 kB Not a huge difference but not exactly minor either. And of course LINGUAS="" wouldn't be shown at all if nothing had changed with regard to it and --verbose wasn't specified. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 16:43, Ciaran McCreesh wrote: > On Mon, 30 Jan 2006 06:17:36 +0100 "Diego 'Flameeyes' Pettenò" > <[EMAIL PROTECTED]> wrote: > | Also, as repoman complain about linguas_blabla not being a valid > | useflags, all the linguas_* useflags should be listed in use.desc > > No, part of the point of USE_EXPAND is that they shouldn't. This is a > repoman bug. I have yet to be enlightened on any merit of USE_EXPAND is so perhaps you could explain as to why there should be user-configured-yet-undocumented options for ebuilds? More precisely, how should they be documented if not via use.desc? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Unmasking modular X
On Tuesday 31 January 2006 13:49, Joshua Jackson wrote: > Mark Loeser gentoo.org> writes: > > Donnie Berkholz gentoo.org> said: > > > Jason Stubbs wrote: > > > > The patch now has the debugging output and x11-base/xorg-x11 check > > > > removed. > > > > > > Excellent. Works perfectly. Since we're failing on them, perhaps we can > > > say "obsolete" instead of "deprecated"? > > > > Can we put this back to being a warning? It makes things a pain for arch > > teams that are trying to mark a completely unrelated version of the > > package. > > I will have to agree that this change has made it a pain to mark anything > stable. I had 4 out of the 6 I did today bail out because of this. I took > the simple easy fix and removed the check to stabalize the packages I needed > to. I know we have people who want modular X yesterday, but causing trouble > for dev's going about business that doesn't involve the modular problems > directly is only going to cause resentment and frustration to all the teams > involved. Is there any need for the packages to go into stable without the X deps being fixed? Why not just open a bug for the package maintainer and mark it against whatever bug is requesting stabling of that package? Moving something to stable that you know is going to be broken within a relatively short timeframe seems like a very bad idea... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 20:54, Ciaran McCreesh wrote: > On Mon, 30 Jan 2006 20:46:28 +0900 Jason Stubbs <[EMAIL PROTECTED]> > wrote: > | On Monday 30 January 2006 16:43, Ciaran McCreesh wrote: > | > On Mon, 30 Jan 2006 06:17:36 +0100 "Diego 'Flameeyes' Pettenò" > | > <[EMAIL PROTECTED]> wrote: > | > | Also, as repoman complain about linguas_blabla not being a valid > | > | useflags, all the linguas_* useflags should be listed in use.desc > | > > | > No, part of the point of USE_EXPAND is that they shouldn't. This is > | > a repoman bug. > | > | I have yet to be enlightened on any merit of USE_EXPAND is so perhaps > | you could explain as to why there should be > | user-configured-yet-undocumented options for ebuilds? More precisely, > | how should they be documented if not via use.desc? > > 1. Because for things like LINGUAS, there are arbitrarily many legal > values, and documenting them all and keeping the list up to date would > be extremely difficult. "More precisely, how should they be documented if not via use.desc?" > 2. Because USE_EXPAND is used for special USE things like arch and > userland, and because we undocumented the special arch USE flags > because they're not user settable. These variables are internal and not meant to be user configurable. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Unmasking modular X
On Wednesday 01 February 2006 02:28, Mark Loeser wrote: > Jason Stubbs <[EMAIL PROTECTED]> said: > > Is there any need for the packages to go into stable without the X deps > > being > > fixed? Why not just open a bug for the package maintainer and mark it > > against > > whatever bug is requesting stabling of that package? Moving something to > > stable that you know is going to be broken within a relatively short > > timeframe seems like a very bad idea... > > We are talking about completely unrelated versions, not what we are touching. > For example, old imagemagick ebuilds sitting around, where the newer ebuilds > are fixed, but old ones are not. We have a security bug open about this > package right now, and having an error about deps in some old version doesn't > really help arch teams at all. Security bugs are about the only time I can see any urgency. That's not a good reason to completely degrade the error though. A switch similar to --ignore-other-archs that skips certain checks for urgent fixes seems reasonable though. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Tuesday 31 January 2006 22:39, Mike Frysinger wrote: > On Tuesday 31 January 2006 06:31, Jason Stubbs wrote: > > On Monday 30 January 2006 20:54, Ciaran McCreesh wrote: > > > 1. Because for things like LINGUAS, there are arbitrarily many legal > > > values, and documenting them all and keeping the list up to date would > > > be extremely difficult. > > > > "More precisely, how should they be documented if not via use.desc?" > > considering there's a ton more LINGUAS values than we have USE flags (just > run > `wc` on use.desc and lang.desc), bloating use.desc with LINGUAS settings > benefits *noone* > > we have lang.desc, it is quite populated, what's wrong with having portage > read that Absolutely nothing. I am in no way suggesting that use.desc is the possible fix. I wasn't even suggesting that each individual flag need be documented. However, if lang.desc already exists (and it does) and can be renamed to linguas.desc, it is probably a better way to manage it than use.desc. Is having INPUT_DEVICES and the like following the same scheme (ie, input_devices.desc) acceptable? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Binary packages
On Thursday 09 February 2006 08:19, Mark Loeser wrote: > Anyone that is maintaining a binary package in the tree, and requires > libstdc++-v3, please put a rdepend in your package on > =virtual/libstdc++-3.3. I'd like to drop the dependency from gcc-3.4 and > higher so that we do not needlessly force the libstdc++ package on people > that do not need it. It was my understanding that it is needed for the 3.3 -> 3.4 upgrade. Various packages that will build fine against either are broken until being recompiled after the upgrade and there is currently no way to express this with dependencies. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Binary packages
On Thursday 09 February 2006 09:30, Mark Loeser wrote: > Jason Stubbs <[EMAIL PROTECTED]> said: > > It was my understanding that it is needed for the 3.3 -> 3.4 upgrade. > > Various packages that will build fine against either are broken until > > being recompiled after the upgrade and there is currently no way to > > express this with dependencies. > > You need either gcc-3.3 or libstdc++-v3. I don't see forcing either upon our > users to be a good thing. The upgrade doc covers how to do the 3.3->3.4 > upgrade, and I think most archs are on 3.4 at this point. Ok. If the there's an upgrade doc and 3.4 postinst points to it, no problem. I take it the dependencies you're asking about is for binary-only (or other?) packages that specifically depend on 3.3 then? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Passing the buck
On Thursday 09 February 2006 15:00, Brian Harring wrote: > On Sun, Feb 05, 2006 at 03:04:08PM +0900, Jason Stubbs wrote: > > Hi all, > > > > Time again for one of those mails; this time from me. Due to time > > constraints, > > real life and coming close to burning out I'm stepping down as release > > coordinator. Brian has graciously accepted shouldering the burden until he > > starts to burn out or some insane bugger comes along and wrestles him for a > > slice of the action. > > And I suck, because I'm going to pass the buck now. > > The .5x release, and 2.1.pre5 realease I'll handle; if 2.1 proves > stable, and doesn't take forever I'll see it through, but I'm taking > at least a hiatus from gentoo. I'll pull it back if you like, but it means I'll pretty much not have time for anything else. While I've been fed up with the bullshit myself in the past, the feeling is somewhat subdued at the moment so I can get right back into it if you like. Not that I stopped reading through the commits anyway; habits are hard to break. ;) I'll have a little more time than I estimated for the time being anyway. Dell wants us to pay $35K for the hardware and then $50K+ on top of that for them to configure and install the redhat on it all. :/ (== SAN has been postponed) Long term, same deal though. Perhaps it would be a good idea to get those interested in it together and can try to get some documentation together. That should at least make the executor less important... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Passing the buck
On Thursday 09 February 2006 20:23, Jason Stubbs wrote: ... Wrong list :/ -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] "emerge -NDuvp world" takes forever after "emerge sync"
On Saturday 25 February 2006 18:39, Sebastian Bergmann wrote: > For a while I am experiencing the following portage annoyance: > > After an "emerge sync" (for which the metadata/cache update takes about > ten seconds), the first call to "emerge -NDuvp world" takes between > five and ten minutes > >emerge -NDuvp world 321.05s user 77.90s system 94% cpu 7:02.77 total > > I am using sys-apps/portage-2.1_pre4-r1. Open a bug for this please. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Saturday 04 March 2006 23:45, Danny van Dyk wrote: > Am Samstag, 4. März 2006 14:24 schrieb Thomas de Grenier de Latour: > > One point of view on this issues is that the ebuilds are wrong, because > > they are abusing the said USE flags, and they should rather die. Imho, > > it makes sense, but if such a strict policy was applied to every > > ebuilds which atm are abusing flags this way, it would become really > > hard to put anything in the make.conf USE variable without breaking > > "emerge -uD world". > > Just to throw in my 2 cents into this discussion: I'm all against die-ing > during the update process. However, i think that stopping before the update > process would be the best solution at hand. I'd like to propose the addition > of a dedicated USE conflict detection to ebuilds which need it. This sounds the most reasonable. I can't see portage ever supporting "the 'foo' and 'bar' flags can be used together except when 'baz' is also used" type flag interdepency complexity. As Mike pointed out, check_license also needs to be accounted for as well as possible others. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE_EXPAND in IUSE ( again )
On Saturday 11 March 2006 14:19, Alec Warner wrote: > Either USE_EXPAND always goes in IUSE, or USE_EXPAND never goes in IUSE. Regardless of what is displayed, portage will eventually need to know what USE_EXPAND env vars are modifying the behaviour of an ebuild. Consider extending --newuse to support USE_EXPAND as well. Simply knowing the var itself isn't quite enough. Could you imagine if every single package that is modified by USE were recompiled when irrelevant parts of USE is changed? > If you want USE_EXPAND that sometimes goes in IUSE and sometimes doesn't > you better have a good plan for keeping those lists of proper USE_EXPAND > flags and improper flags in sync. I mean I'd love to do it that way, > but I'll bet those lists get old and nasty and we will have people > complaining about QA warnings that they thought were fixed or that there > were no QA warnings when there should have been...etc.. I also committed support for a USE_EXPAND_HIDDEN. Individual flags don't need to be added to it. USE_EXPAND_HIDDEN="USERLAND ARCH ..." is enough. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
