Re: [gentoo-dev] New category: net-voip
On Sat, 22 Jul 2006 21:42:07 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sat, 22 Jul 2006 18:04:10 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | If it were to be implemented with symlinks (implying one entry is | real and the others are aliases) the package manager just needs to | canonicalise any symlinked CPs it comes across. Not that simple. Think about installed packages, overlays and changing aliases. The package manager would need to keep track of what aliases were at any given time. Not if the aliases are resolved to the canonical CP when they are parsed. At any point in time, the dep resolver would be working with canonical CPs as they exist at that point, not what they were when the package was installed or the binpackage was built. Then there're symlinks to outside the tree and Maybe I've misunderstood you here, but surely aliasing from inside the tree to outside it (e.g. to an overlay package not present in the primary tree) would not be sensible. circular symlinks... There's a lot more too it than is initially obvious. My understanding is that circular dependencies are not supported; the situation would be no different with aliasing, pretty much by definition if nothing else - all aliases should ultimately resolve to a real package, which they can't do if you allow circular aliases. | Since we can't have symlinks in CVS, there are other ways it can be | done; first thing that pops into my head is an alias package entry | in the tree, where instead of ebuilds files/ etc it would just | contain a file alias with the category (and perhaps package name) | of the aliased package. Files are cleaner than symlinks for other reasons too. Also allows the opportunity of making 'deprecated' aliases that issue QA warnings. | Has to walk the entire tree... so if N category per pkg is going to | be proposed, need to preserve the fast lookup that's there now. | | I don't think the above ideas cause any substantial change to the | amount of processing required. Perhaps you should think. It's nowhere near as straight forward as you claim. Which is not to say it's not doable, just that it's not doable cheaply... I still don't see how, if aliases are canonicalised when they are parsed, the issue becomes more complex. Internally the package manager would always think in terms of the canonical CP, at which point it's not doing anything that it isn't already. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Sat, 22 Jul 2006 13:35:08 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Sat, Jul 22, 2006 at 06:04:10PM +0200, Kevin F. Quinn wrote: On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring [EMAIL PROTECTED] wrote: Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Just so we're clear, I probably will wedgie anyone who suggests trying to extend the existing tree format with N categories per pkg- sounds nice on paper, but it makes lookup a serious pita- sys-apps/portage, we'll pretend it's actually located in sys-apps, and it's also in category 'pkg-managers'. An atom states 'pkg-managers/portage'; how does a pkg manager do a lookup for it? Since the names would be aliased, either reference would be fine i.e. a dep on pkg-managers/portage would be equivalent to sys-apps/portage. If it were to be implemented with symlinks (implying one entry is real and the others are aliases) the package manager just needs to canonicalise any symlinked CPs it comes across. Since we can't have symlinks in CVS, there are other ways it can be done; first thing that pops into my head is an alias package entry in the tree, where instead of ebuilds files/ etc it would just contain a file alias with the category (and perhaps package name) of the aliased package. I would expect it to be non-trivial to implement in portage, since portage code has evolved for so long assuming that a package is in one category - I'm not saying portage code is bad, I'm just saying that much of it may have been implemented under that assumption and breaking it means testing lots of stuff. Has to walk the entire tree... so if N category per pkg is going to be proposed, need to preserve the fast lookup that's there now. I don't think the above ideas cause any substantial change to the amount of processing required. An advantage to this approach is that package moves just become aliases - existing stuff doesn't break yet you get the new categorisation as well. A disadvantage being that without a tree, your graph is broken (aliases live in the tree); this includes using strictly a bintree (remote or otherwise). I don't get what you're talking about here; perhaps I'm missing something. I don't see why the deps can't be managed by canonicalising every reference as they are parsed. As you build the graph, the aliases disappear as they are canonicalised before they reach the graph. That way the only place aliases exist is in the portage tree itself - the package manager can forget about them once it has parsed the deps. Certainly trying to build the dependency tree without canonicalising aliases would be a mess; anyone trying to do it like that is asking for trouble. You want unique names for everything for which you're building the dependency tree. Big disadvantage, hence why that approach was ignored last time it was brought up. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Sun, 23 Jul 2006 12:19:28 +0100
Stuart Herbert [EMAIL PROTECTED] wrote:
Kevin F. Quinn wrote:
An advantage to this approach is that package moves just become
aliases
- existing stuff doesn't break yet you get the new categorisation as
well.
That's actually a disadvantage. The whole point of moving a package
is to take it *out* of its existing category.
No, the point is to take it from a category where it's membership is
not so strong, to one where it is stronger. For exmaple, it's not that
net-im is the wrong place for skype, it's just that net-voip is in some
ways better. Where categorisation is clearly very wrong then it should
be moved as soon as possible (for example if skype had initially been
placed in www-apps) but that's an initial commit problem rather than
maintenance going forward.
Just adding an alias
into a second category makes the tree more of a mess - not less.
The alias, once setup, can be left alone forever. As far as any
further maintenance is concerned, it requires none. Even if the
package is moved again, the alias can still point to the second
location which becomes an alias for the final location. As far as
users are concerned, assuming aliases are resolved when being parsed,
they would see:
$ emerge -p net-im/skype
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] net-voip/skype-1.3.0.30-r1
(where net-voip/skype is copied from net-im/skype, then net-im/skpe is
rewritten as an alias), which is clear and simple (it's hardly more
than what emerge does if you only give it the package name). Aliases
can be ignored when the category is not specified (unless we permit
aliasing with different package names, which I suggest we do not).
Similarly with 'emerge -s' - it would return the canonical CP.
The only mess is that we end up with the alias data in the tree
and that gradually accumulates. However it won't change once it's first
setup so won't incur any significant synchronisation overhead (beyond
the overhead for the actual move as done currently). I've mentioned the
CP/alias idea elsewhere, however that's not the only way to do it -
one simple method could be to have a simple text file (e.g.
${PORTDIR}/profiles/alias) listing all the aliases. That's no mess at
all:
example alias file contents
# Alias category/package Resident category
net-im/skype net-voip
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] New category: net-voip
Stuart Herbert wrote: Kevin F. Quinn wrote: An advantage to this approach is that package moves just become aliases - existing stuff doesn't break yet you get the new categorisation as well. That's actually a disadvantage. The whole point of moving a package is to take it *out* of its existing category. Just adding an alias into a second category makes the tree more of a mess - not less. +1 I really dislike this idea of aliasing ebuild categories, yuck... Way better to fix what needs to be fixed to make package moves as smooth and seamless as possible. -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: net-voip
On Mon, Jul 24, 2006 at 02:47:46PM +0200, Kevin F. Quinn wrote:
On Sun, 23 Jul 2006 12:19:28 +0100
Stuart Herbert [EMAIL PROTECTED] wrote:
Just adding an alias
into a second category makes the tree more of a mess - not less.
The alias, once setup, can be left alone forever. As far as any
further maintenance is concerned, it requires none. Even if the
package is moved again, the alias can still point to the second
location which becomes an alias for the final location.
That implicitly means that any second level categorizations can never
be removed.
Like stuart said, makes a bigger mess of the tree. Package moves can
be disruptive enough- trying to shift out a non-real category is going
to be a much larger mess of building that tree and trying to rewrite
atoms as needed.
As far as
users are concerned, assuming aliases are resolved when being parsed,
they would see:
$ emerge -p net-im/skype
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] net-voip/skype-1.3.0.30-r1
That doesn't strike you as a bit... daft? they asked for net-im, not
net-voip. Yes, under your scheme, they're the same- that still is far
from intuitive.
The only mess is that we end up with the alias data in the tree
and that gradually accumulates.
Err... cruft accumulating in the tree is a no go.
However it won't change once it's first
setup so won't incur any significant synchronisation overhead (beyond
the overhead for the actual move as done currently).
A) potential of circular aliasing (fun fun)
B) potential of aliasing multiple pkgs to the same cat (fun fun)
C) pkgs that grow capabilities after a certain version, thus they now
belong in a new category. Now we require full atoms for aliasing
(which means lookup gets more complicated now, and slower)
D) all tree access now must pass through aliasing. Additionally, now
all equality tests must now rely on aliasing to determine if two
pkgs from seperate categories are actually the same pkg (slower, and
far more complicated)
Fair amount of thorny issues introduced there, for (imo) no real gain.
I've mentioned the
CP/alias idea elsewhere, however that's not the only way to do it -
one simple method could be to have a simple text file (e.g.
${PORTDIR}/profiles/alias) listing all the aliases. That's no mess at
all:
example alias file contents
# Alias category/package Resident category
net-im/skype net-voip
As I said (and you seemed to have ignored), mandating tree access to
use the vdb or a standalone binpkg repository == no go.
~harring
pgpIr8sQDiWLN.pgp
Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Mon, 24 Jul 2006 06:23:59 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Mon, Jul 24, 2006 at 02:47:46PM +0200, Kevin F. Quinn wrote: On Sun, 23 Jul 2006 12:19:28 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: Just adding an alias into a second category makes the tree more of a mess - not less. The alias, once setup, can be left alone forever. As far as any further maintenance is concerned, it requires none. Even if the package is moved again, the alias can still point to the second location which becomes an alias for the final location. That implicitly means that any second level categorizations can never be removed. By second level categorizations do you mean the intermediate alias? The intermediate alias will exist anyway, as an alias in its own right. If any alias is to be removed, then clearly any references to it need to be cleaned up. This is the case whether the alias in question is part of a chain or not. Also this is no worse a situation than current package moves - a fixpackages-style patch-up becomes necessary at that point (more on removal below). Having said all that, I do think the single alias file approach would be better, and it would be simple then to require all aliases to refer directly to the real category. This would indeed require some maintenance, but not exactly back-breaking, just one file for the maintainer of the package that is being moved to check for existing aliases to the previous location. Like stuart said, makes a bigger mess of the tree. Package moves can be disruptive enough- trying to shift out a non-real category is going to be a much larger mess of building that tree and trying to rewrite atoms as needed. I disagree, it's not a mess. It's better for existing installations as the old CP still works - so to my mind you get the best of both worlds; you can move the package to whatever category the maintainer thinks is the best, without having to hack around all over the place (which currently leaves standalone installations in the dark, btw) to clean up. As far as users are concerned, assuming aliases are resolved when being parsed, they would see: $ emerge -p net-im/skype These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] net-voip/skype-1.3.0.30-r1 That doesn't strike you as a bit... daft? they asked for net-im, not net-voip. Yes, under your scheme, they're the same- that still is far from intuitive. No, it seems simple enough to me. Someone who has previously installed skype from the net-im category, may remember it was in net-im and type the command I illustrated. However the package has moved to net-voip, and emerge has done the right thing - managed the alias and gone to the correct package. If you really wanted to be verbose about it, it could go like: $ emerge -p net-im/skype These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] net-voip/skype-1.3.0.30-r1 [*] [*] package moved to highlight to the user the package has moved. Currently that same user would do: $ emerge -p net-im/skype These are the packages that would be merged, in order: Calculating dependencies emerge: there are no ebuilds to satisfy net-im/skype. [bum - where has Skype gone? hmm; perhaps it's somewhere else] $ insert favourite package searching mechanism here $ emerge -p net-voip/skype ... Note that since alias names would be ignored if the category is not specified, 'emerge -p skype' would just work in the way it does now. Note also that if a new package is added with the same name, and that package goes in what was once an alias location, the package manager requires you to specify which one you want. The only mess is that we end up with the alias data in the tree and that gradually accumulates. Err... cruft accumulating in the tree is a no go. What, like eclasses and ChangeLogs? It's history, rather than cruft. It has meaning to existing installations, as does legacy code in eclasses. I illustrated elsewhere that it could easily be implemented by a simple text file, nothing more intrusive than package.mask et. al. However it won't change once it's first setup so won't incur any significant synchronisation overhead (beyond the overhead for the actual move as done currently). A) potential of circular aliasing (fun fun) Circular aliasing is obviously broken and should not be committed. Any such occurrences should be fixed promptly, and the committer slapped. It's also easy to detect. However it's a good reason to require all aliases to be direct (i.e. no aliases of aliases). B) potential of aliasing multiple pkgs to the same cat (fun fun) Ditto :) C) pkgs that grow capabilities after a certain version, thus they now belong in a new category. Now we require full atoms for aliasing (which means lookup gets more complicated
Re: [gentoo-dev] New category: net-voip
On Mon, 24 Jul 2006 17:50:42 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | As I said (and you seemed to have ignored), mandating tree access | to use the vdb or a standalone binpkg repository == no go. | | I didn't ignore it - I didn't get it when you first said it. What | you're saying (?) is that to install a binpkg (for example), if the | tree is present it would resolve the category that the binpkg was | created under (that is now aliased) to the new category using the | alias data in the tree, and store stuff in the vdb under that new | category, purging out the entry in the vdb from the old category | (hence using tree data in the standalone case). Obviously this is | the correct behaviour when the tree is present. | | I'd suggest that in the absence of a tree, operations would assume no | aliasing (since all aliases at the time the vdb or binpkg were created | would already have been resolved), so the system state is still | consistent with the aliasing in force when the packages were built. Won't work, which is a large part of why this thing isn't as simple as you're assuming. The only way of handling it correctly is to keep track, with *each individual binary / vdb entry*, of all the names that have pointed to it at any given time between when it was created and current... Think through all the cases involving alias changing, removing etc. There're rather a lot of them, and a solution that handles all said cases sanely is unfortunately not going to be anything like straighforward. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
Jakub Moc wrote: as .cfg_** files. The end user still has to run an etc-update and pray that it was not a file he/she had in masking. Err, no? You don't need to run etc-update/dispatch-conf to get those updated on package moves. Incorrect. You do have to run etc-update/dispatch-conf. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: net-voip
Kevin F. Quinn wrote: An advantage to this approach is that package moves just become aliases - existing stuff doesn't break yet you get the new categorisation as well. That's actually a disadvantage. The whole point of moving a package is to take it *out* of its existing category. Just adding an alias into a second category makes the tree more of a mess - not less. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: net-voip
On Thu, 20 Jul 2006 13:24:55 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, Jul 20, 2006 at 08:41:46PM +0200, Kevin F. Quinn wrote: On Thu, 20 Jul 2006 00:37:47 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: On Wed, 19 Jul 2006 17:15:38 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 19 Jul 2006 08:57:32 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Things that package moves cause: | 1) Dependencies throughout the tree have to be updated And? This isn't a breakage. It is however unnecessary inconvenience for the user, even assuming the support for moves is bug-free. Think you're ignoring that proper categorization *is* useful to the user. One of the costs of that is moving when necessary. My main point is that proper categorisation is subjective. What should be in net-voip for some people, should be in net-im for others (since many packages provide functionality in both areas). Thus whether or not it moves are necessary is subjective. How often does a package lie equally across multiple categories? I think your point (pulling probably fairly close figures out of the head) is relevant to all of 100 or so packages in the tree, out of 11k. Pretty much anything in the sys-* categories, for a start. Then there's dev-libs - many packages provide libs and a simple app to use them, so where do they go? In *-libs or a category for the simple app? Sounds of it, you don't much care for categorizatin- that's fine, please keep in mind some people do find it a net gain to maintain the categorization however. I'm happy with the idea of categorisation in general, I do however think that the categorisation in the tree as it stands is simply inadequate. Examples would be lovely- numerous examples specifically. Please keep in mind the tree holds (as of about 15 hours back) 11,212 packages. Pointing at one or two packages to label all categorization as inadequate won't suffice, going to need to clear at *least* 1% of the tree to back that assertion up. I'm not going to waste time going through 11k+ packages to show you that many packages provide functionality that applies to more than one category; it seems obvious to me. Some categories are better than others - games-* for example, because those apps tend to be designed to fit a category in the first place. The problems arise when categorisation occurs in more than one direction (e.g. sys-* overlaps other categories) or when categorisation has become so tight that few packages fit only in such categories (which is what I think is happening with the net-im/voip categorisation). | 3) Binary packages go out-of-date So rebuild them. Binary packages go out of date whenever someone does a version bump too. So your opinion is that it's fine to cause users to rebuild stuff even when the package itself hasn't changed? You're ignoring what fixpackages does. Ever noticed how it's far faster when you don't have buildpkgs enabled? ;) I certainly noticed how much time is lost when fixpackages chunters through built packages to fix stuff up. My usual response to criticism of that sort applies- you know where the src is ;) My understanding is that the amount of time it takes to fix up binary packages is down to having to unpack, tweak, then re-pack - the unpack and re-pack are what consume the resource. Any alternative would involve changing the package format. Doing things *correctly* isn't always the same as doing things *fast*. Throwing correctness bits out in the name of speed is a no go (iow, fixpackages ought to be nonoptional). I agree - however this for me is an argument to avoid package moves unless the move is very necessary. Again, you may not view categories as useful, but others may. My experience with categories as they stand, is that to find a package whose location I don't already know I have to search all categories anyway - it's certainly not possible to predict in which category a package lives. Not much experience then. Your use scenario above is I'm looking for a package, not I'm trying to find packages in category x. Huh? That's my point - if I'm looking for a package I often don't know what category it is until I find it. Some categories are better than others in this respect. The point remains though that categories are one-to-one, where as many packages provide functionality in more than one area (one-to-many). You can do one-to-many in a directory structure by using links (symbolic or hard) - however CVS doesn't support them, and the dep resolver won't cope with that at the moment (it could be made to without too much trouble, I think). Of course categories don't matter to you in your case- you're not *using* them. What others are talking about how ever is
Re: [gentoo-dev] New category: net-voip
On Wed, 2006-07-19 at 17:10 +0100, Ciaran McCreesh wrote: On Wed, 19 Jul 2006 11:10:51 -0400 Ned Ludd [EMAIL PROTECTED] wrote: | Every single year quarter after quarter the more updates | that happen the slower portage is becoming. | Care to solve that? This is a minute amount of time in comparison to anything significant. If you care about Portage speed, you'd be far better off reducing the number of packages that users have installed and reducing the number of packages in the tree. | My fix would be to remove the ability to do package moves | from portage all together. Which makes me rather glad that you're not fixing anything... | |i dont think this sort of thing should hold up tree | shuffles ... | | Well it should. | | package.keywords package.use package.mask etc.. | | Where is the stability and consistency when we end up | forcing people to update /etc/portage files... Erm... Portage updates these automatically. as .cfg_** files. The end user still has to run an etc-update and pray that it was not a file he/she had in masking. None the less I think you missed the part in the tread along time ago which Stefan said he would do the moves at the same time as bumps. Doing it that way solves most of the problems. Granted not all of them like the vdb/*DEPEND entries of other pkgs. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
Ned Ludd wrote: | Well it should. | | package.keywords package.use package.mask etc.. | | Where is the stability and consistency when we end up | forcing people to update /etc/portage files... Erm... Portage updates these automatically. as .cfg_** files. The end user still has to run an etc-update and pray that it was not a file he/she had in masking. Err, no? You don't need to run etc-update/dispatch-conf to get those updated on package moves. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: net-voip
Jakub Moc wrote: Erm... Portage updates these automatically. as .cfg_** files. The end user still has to run an etc-update and pray that it was not a file he/she had in masking. Err, no? You don't need to run etc-update/dispatch-conf to get those updated on package moves. Err, yes. At least here you do. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring [EMAIL PROTECTED] wrote: Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Just so we're clear, I probably will wedgie anyone who suggests trying to extend the existing tree format with N categories per pkg- sounds nice on paper, but it makes lookup a serious pita- sys-apps/portage, we'll pretend it's actually located in sys-apps, and it's also in category 'pkg-managers'. An atom states 'pkg-managers/portage'; how does a pkg manager do a lookup for it? Since the names would be aliased, either reference would be fine i.e. a dep on pkg-managers/portage would be equivalent to sys-apps/portage. If it were to be implemented with symlinks (implying one entry is real and the others are aliases) the package manager just needs to canonicalise any symlinked CPs it comes across. Since we can't have symlinks in CVS, there are other ways it can be done; first thing that pops into my head is an alias package entry in the tree, where instead of ebuilds files/ etc it would just contain a file alias with the category (and perhaps package name) of the aliased package. I would expect it to be non-trivial to implement in portage, since portage code has evolved for so long assuming that a package is in one category - I'm not saying portage code is bad, I'm just saying that much of it may have been implemented under that assumption and breaking it means testing lots of stuff. Has to walk the entire tree... so if N category per pkg is going to be proposed, need to preserve the fast lookup that's there now. I don't think the above ideas cause any substantial change to the amount of processing required. An advantage to this approach is that package moves just become aliases - existing stuff doesn't break yet you get the new categorisation as well. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Sat, Jul 22, 2006 at 06:04:10PM +0200, Kevin F. Quinn wrote: On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring [EMAIL PROTECTED] wrote: Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Just so we're clear, I probably will wedgie anyone who suggests trying to extend the existing tree format with N categories per pkg- sounds nice on paper, but it makes lookup a serious pita- sys-apps/portage, we'll pretend it's actually located in sys-apps, and it's also in category 'pkg-managers'. An atom states 'pkg-managers/portage'; how does a pkg manager do a lookup for it? Since the names would be aliased, either reference would be fine i.e. a dep on pkg-managers/portage would be equivalent to sys-apps/portage. If it were to be implemented with symlinks (implying one entry is real and the others are aliases) the package manager just needs to canonicalise any symlinked CPs it comes across. Since we can't have symlinks in CVS, there are other ways it can be done; first thing that pops into my head is an alias package entry in the tree, where instead of ebuilds files/ etc it would just contain a file alias with the category (and perhaps package name) of the aliased package. I would expect it to be non-trivial to implement in portage, since portage code has evolved for so long assuming that a package is in one category - I'm not saying portage code is bad, I'm just saying that much of it may have been implemented under that assumption and breaking it means testing lots of stuff. Has to walk the entire tree... so if N category per pkg is going to be proposed, need to preserve the fast lookup that's there now. I don't think the above ideas cause any substantial change to the amount of processing required. An advantage to this approach is that package moves just become aliases - existing stuff doesn't break yet you get the new categorisation as well. A disadvantage being that without a tree, your graph is broken (aliases live in the tree); this includes using strictly a bintree (remote or otherwise). Big disadvantage, hence why that approach was ignored last time it was brought up. ~harring pgpAtePs43wy7.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Sat, 22 Jul 2006 18:04:10 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | If it were to be implemented with symlinks (implying one entry is | real and the others are aliases) the package manager just needs to | canonicalise any symlinked CPs it comes across. Not that simple. Think about installed packages, overlays and changing aliases. The package manager would need to keep track of what aliases were at any given time. Then there're symlinks to outside the tree and circular symlinks... There's a lot more too it than is initially obvious. | Since we can't have symlinks in CVS, there are other ways it can be | done; first thing that pops into my head is an alias package entry | in the tree, where instead of ebuilds files/ etc it would just | contain a file alias with the category (and perhaps package name) | of the aliased package. Files are cleaner than symlinks for other reasons too. Also allows the opportunity of making 'deprecated' aliases that issue QA warnings. | Has to walk the entire tree... so if N category per pkg is going to | be proposed, need to preserve the fast lookup that's there now. | | I don't think the above ideas cause any substantial change to the | amount of processing required. Perhaps you should think. It's nowhere near as straight forward as you claim. Which is not to say it's not doable, just that it's not doable cheaply... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On 7/19/06, Kevin F. Quinn [EMAIL PROTECTED] wrote: In my opinion moving packages from one category to another just causes unnecessary disruption to the tree - all relevant dependencies throughout the tree have to be altered, putting current installations out-of-date with respect to it. Some other folk hold a different opinion. It's both perfectly natural and desirable for packages to migrate out of -misc type categories into more targetted categories over time. We've done it in the past, and it's something we need to be able to continue to do in the future. It helps folks look for things when they don't know the name of what they're looking for, and it stops -misc type categories from becoming dumping grounds. The key issue is that categories are semantically inadequate. Do you have any evidence to show that this is a widely-held opinion? Have you done any research amongst the wider user community to find out how they view categories? Deciding which category a package fits into is subjective, frequently a package fits into many categories yet the category system insists that a package belong to one and only one category. All classification systems are subjective, imperfect, and prone to change over time. Portage's is no worse than any other in this respect. (What is worse is the way Portage copes with change ... I agree with Mike here, we should be fixing our tools, rather than being artificially restricted by them). Usually these big package moves occur when people want to align herds with categories, which is a waste of time - also it's daft as packages can sensibly belong to more than one herd. Unfortunately we see a lot of it in the tree. You think it's daft, but that's just one perspective. What would you prefer? A tree where packages never ever move category? Christ, if we followed that dogma, then categories really would be useless, because we'd have far too many packages filed in the wrong place, or in general catchall -misc type categories. I think it's more important that the tree can be flexible, and can change structure over time. This week it's packages that have voip functionality that are being moved to net-voip. In six months time it'll be someone else wanting to move all packages with IM functionality into net-im. In herd-speak, these packages could easily belong to both the voip and im herds, should such exist; those providing c++ libraries could also belong to the cpp herd. This is useful, as the maintainers of those herds can each deal with issues in their field. It doesn't matter which category it's in. It seems a bit odd that a language herd like cpp (using your own example) would maintain a package just because the package itself is written in cpp, irrespective of what the package actually does. For example, the PHP herd is focused on packages that provide the PHP language and it's supporting infrastructure ... not on applications that are written in PHP. Those are left to other herds, who are more expert in the problems that those applications solve. The only concrete thing categories give us is the ability to have two packages with the same upstream name without having to mangle the upstream name. Not true. They provide us with an organisational ability too, whether its grouping packages to ensure people don't dump stuff in the tree (dev-perl being the classic example here), grouping packages by origin (gnome-*) or by common purpose (sys-fs). If a user needs something, but doesn't know which package they want, they can look inside the relevant category, and see what their choices are. In fact, categories do not give us the complete ability to have two packages with the same upstream name in the tree ... because binary packages do not support category names at all. Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Fri, Jul 21, 2006 at 08:44:35AM +0100, Stuart Herbert wrote: In fact, categories do not give us the complete ability to have two packages with the same upstream name in the tree ... because binary packages do not support category names at all. B. They do actually- the bintree *repository* format flattens the namespace, thus screwing the ability to use category as part of the key for lookup. That said, the binpkgs themselves still carry their original category. Fixing the namespace flattening is easy for bintrees- problem is it'll screw over remote binhost implementation, which relies on remote listdir (essentially) of the All directory to figure out what's available. Personally I'd be inclined to give existing remote bintree implementation the boot (ugly code, slow due to it's design), but others will bitch. Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Just so we're clear, I probably will wedgie anyone who suggests trying to extend the existing tree format with N categories per pkg- sounds nice on paper, but it makes lookup a serious pita- sys-apps/portage, we'll pretend it's actually located in sys-apps, and it's also in category 'pkg-managers'. An atom states 'pkg-managers/portage'; how does a pkg manager do a lookup for it? Has to walk the entire tree... so if N category per pkg is going to be proposed, need to preserve the fast lookup that's there now. ~harring pgpTR3jYhLxtZ.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Wed, 19 Jul 2006 11:10:51 -0400 Ned Ludd [EMAIL PROTECTED] wrote: | Every single year quarter after quarter the more updates | that happen the slower portage is becoming. | Care to solve that? This is a minute amount of time in comparison to anything significant. If you care about Portage speed, you'd be far better off reducing the number of packages that users have installed and reducing the number of packages in the tree. | My fix would be to remove the ability to do package moves | from portage all together. Which makes me rather glad that you're not fixing anything... | |i dont think this sort of thing should hold up tree | shuffles ... | | Well it should. | | package.keywords package.use package.mask etc.. | | Where is the stability and consistency when we end up | forcing people to update /etc/portage files... Erm... Portage updates these automatically. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring [EMAIL PROTECTED] wrote: | Just so we're clear, I probably will wedgie anyone who suggests | trying to extend the existing tree format with N categories per pkg- | sounds nice on paper, but it makes lookup a serious pita- | sys-apps/portage, we'll pretend it's actually located in sys-apps, | and it's also in category 'pkg-managers'. An atom states | 'pkg-managers/portage'; how does a pkg manager do a lookup for it? If you're looking to preserve linear / log-linear lookup times, you do it by having two types of object: 'real' packages and package aliases. I tried implementing it a while back for Paludis just to see if it'd be of any use. There're a few cases where it might be neat but there's no way it's worth trying to get Portage to do such a thing... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Wed, 19 Jul 2006 17:15:38 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 19 Jul 2006 08:57:32 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Things that package moves cause: | 1) Dependencies throughout the tree have to be updated And? This isn't a breakage. It is however unnecessary inconvenience for the user, even assuming the support for moves is bug-free. | 2) Current installations become inconsistent with respect to the tree Uh, current installations become 'inconsistent' whenever anyone changes *anything* in the tree. To a different degree. In the package move case, the inconsistency occurs even though nothing has really changed, in terms of what the packages actually do. | 3) Binary packages go out-of-date So rebuild them. Binary packages go out of date whenever someone does a version bump too. So your opinion is that it's fine to cause users to rebuild stuff even when the package itself hasn't changed? | 4) Increased sync load Not really significant in comparison to, say, an arch team keywording a new KDE or Gnome stable. The difference with KDE or Gnome going stable is that it actually provides something useful; i.e. an updated version of the packages that are presumably better in some way. Package moves do not improve what the package provides, at all, so you incur the pain for no gain. | 5) Loss of history, unless the move is performed server-side (i.e. | extra work for infra) History's in the ChangeLog. That's a fraction of what's in the CVS history, however. | The key issue is that categories are semantically inadequate. That's no reason to use them improperly. I note you cherry-pick what to respond to. I explained how, without improper use (whatever that is), you just end up with a tug-of-war between herds about which category something should be in. So again, you've *not* given any reasons to avoid sensible package moves. Ah; now you're qualifying. What do you consider to be a sensible package move? I would define it as moves where the package is blatantly in the wrong category (e.g. a voip package being found in the app-text category) rather than moves where the package might be a little more appropriate for one category than another - especially where that judgement is subjective. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: On Wed, 19 Jul 2006 17:15:38 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 19 Jul 2006 08:57:32 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Things that package moves cause: | 1) Dependencies throughout the tree have to be updated And? This isn't a breakage. It is however unnecessary inconvenience for the user, even assuming the support for moves is bug-free. Think you're ignoring that proper categorization *is* useful to the user. One of the costs of that is moving when necessary. Sounds of it, you don't much care for categorizatin- that's fine, please keep in mind some people do find it a net gain to maintain the categorization however. | 2) Current installations become inconsistent with respect to the tree Uh, current installations become 'inconsistent' whenever anyone changes *anything* in the tree. To a different degree. In the package move case, the inconsistency occurs even though nothing has really changed, in terms of what the packages actually do. Fundamentally the same thing however. It's metadata changes in the pkg universe, people fixing missing deps on pkgs induce the same thing. Thing to note however is that via fixpackages, the inconsistancy can be corrected (the example I gave above cannot be without a verbump of some sort). | 3) Binary packages go out-of-date So rebuild them. Binary packages go out of date whenever someone does a version bump too. So your opinion is that it's fine to cause users to rebuild stuff even when the package itself hasn't changed? You're ignoring what fixpackages does. Ever noticed how it's far faster when you don't have buildpkgs enabled? ;) It goes through and rewrites the dependencies as needed. So no, doesn't force a rebuild if the user is running with proper options (frankly an option that should be nonoptional). | 4) Increased sync load Not really significant in comparison to, say, an arch team keywording a new KDE or Gnome stable. The difference with KDE or Gnome going stable is that it actually provides something useful; i.e. an updated version of the packages that are presumably better in some way. Package moves do not improve what the package provides, at all, so you incur the pain for no gain. Again, you may not view categories as useful, but others may. | The key issue is that categories are semantically inadequate. That's no reason to use them improperly. I note you cherry-pick what to respond to. I explained how, without improper use (whatever that is), you just end up with a tug-of-war between herds about which category something should be in. Back hand the herds then. If they want to infight, spank their asses. Herds misbehaving doesn't mean everyone else is going to have a pissing match over the categorization of a pkg however- it shouldn't be used as an arguement _against_ proper categorization, since idiot infighting is a whole other problem. So again, you've *not* given any reasons to avoid sensible package moves. Ah; now you're qualifying. What do you consider to be a sensible package move? I would define it as moves where the package is blatantly in the wrong category (e.g. a voip package being found in the app-text category) rather than moves where the package might be a little more appropriate for one category than another - especially where that judgement is subjective. Arguement over how to categorize I'll gladly stay out of, although one comment- for pkgs that are (at the initial time of adding) one of a kind, creating a category for it's specific flavor doesn't make much sense. Couple of months down the line? # of pkgs that would fall into that categorization may warrant it, a scenario that does occur and is a bit relevant to net-voip. ~harring pgpKRM0NKBb6U.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Thu, 20 Jul 2006 09:05:03 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | On Wed, 19 Jul 2006 17:15:38 +0100 | Ciaran McCreesh [EMAIL PROTECTED] wrote: | On Wed, 19 Jul 2006 08:57:32 +0200 Kevin F. Quinn | [EMAIL PROTECTED] wrote: | | Things that package moves cause: | | 1) Dependencies throughout the tree have to be updated | | And? This isn't a breakage. | | It is however unnecessary inconvenience for the user, even assuming | the support for moves is bug-free. Eh? The only thing users see is packages where they'd expect them, which is very convenient. | | 2) Current installations become inconsistent with respect to the | tree | | Uh, current installations become 'inconsistent' whenever anyone | changes *anything* in the tree. | | To a different degree. In the package move case, the inconsistency | occurs even though nothing has really changed, in terms of what the | packages actually do. Uh, changing KEYWORDS doesn't change what the packages actually do, but it does create an inconsistency. | | 3) Binary packages go out-of-date | | So rebuild them. Binary packages go out of date whenever someone | does a version bump too. | | So your opinion is that it's fine to cause users to rebuild stuff even | when the package itself hasn't changed? If they're one of the tree people for whom fixpackages is insufficient, then yes. | | 4) Increased sync load | | Not really significant in comparison to, say, an arch team | keywording a new KDE or Gnome stable. | | The difference with KDE or Gnome going stable is that it actually | provides something useful; i.e. an updated version of the packages | that are presumably better in some way. Package moves do not improve | what the package provides, at all, so you incur the pain for no gain. The gain is a more sensible tree. With the tree as big as it is, that's a very important consideration. | | 5) Loss of history, unless the move is performed server-side (i.e. | | extra work for infra) | | History's in the ChangeLog. | | That's a fraction of what's in the CVS history, however. Then start persuading people to keep better CHangeLogs. The CVS history is still around for when you really need it, of course. | | The key issue is that categories are semantically inadequate. | | That's no reason to use them improperly. | | I note you cherry-pick what to respond to. I explained how, without | improper use (whatever that is), you just end up with a tug-of-war | between herds about which category something should be in. I'd call it snipping out things that're irrelevant to the discussion at hand. Your personal dislike of categories has nothing to do with anything. We're talking about the tree and capabilities that're available, not the tree and capabilities you'd like. | So again, you've *not* given any reasons to avoid sensible package | moves. | | Ah; now you're qualifying. Well yes. It's to prevent you from countering with an absurd example where package moves are abused. Nobody really thinks we should be doing three hundred package moves every day, but I wouldn't put it past certain people to use an argument based around that to say that all package moves are bad... | What do you consider to be a sensible package move? One that makes the tree more consistent and easier to maintain. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Thu, 20 Jul 2006 00:37:47 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: On Wed, 19 Jul 2006 17:15:38 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 19 Jul 2006 08:57:32 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Things that package moves cause: | 1) Dependencies throughout the tree have to be updated And? This isn't a breakage. It is however unnecessary inconvenience for the user, even assuming the support for moves is bug-free. Think you're ignoring that proper categorization *is* useful to the user. One of the costs of that is moving when necessary. My main point is that proper categorisation is subjective. What should be in net-voip for some people, should be in net-im for others (since many packages provide functionality in both areas). Thus whether or not it moves are necessary is subjective. Sounds of it, you don't much care for categorizatin- that's fine, please keep in mind some people do find it a net gain to maintain the categorization however. I'm happy with the idea of categorisation in general, I do however think that the categorisation in the tree as it stands is simply inadequate. | 2) Current installations become inconsistent with respect to the tree Uh, current installations become 'inconsistent' whenever anyone changes *anything* in the tree. To a different degree. In the package move case, the inconsistency occurs even though nothing has really changed, in terms of what the packages actually do. Fundamentally the same thing however. It's metadata changes in the pkg universe, people fixing missing deps on pkgs induce the same thing. No, my point was that there are two types of change to the tree - changes that make a functional difference, and changes that don't. Most changes to the tree fall into the former; however package moves fall into the latter. Thing to note however is that via fixpackages, the inconsistancy can be corrected (the example I gave above cannot be without a verbump of some sort). | 3) Binary packages go out-of-date So rebuild them. Binary packages go out of date whenever someone does a version bump too. So your opinion is that it's fine to cause users to rebuild stuff even when the package itself hasn't changed? You're ignoring what fixpackages does. Ever noticed how it's far faster when you don't have buildpkgs enabled? ;) I certainly noticed how much time is lost when fixpackages chunters through built packages to fix stuff up. These moves are the main reason I removed buildpkgs from FEATURES. That was a while ago now - Duncun suggests it's a lot faster now but I've not tried it recently. It goes through and rewrites the dependencies as needed. So no, doesn't force a rebuild if the user is running with proper options (frankly an option that should be nonoptional). | 4) Increased sync load Not really significant in comparison to, say, an arch team keywording a new KDE or Gnome stable. The difference with KDE or Gnome going stable is that it actually provides something useful; i.e. an updated version of the packages that are presumably better in some way. Package moves do not improve what the package provides, at all, so you incur the pain for no gain. Again, you may not view categories as useful, but others may. My experience with categories as they stand, is that to find a package whose location I don't already know I have to search all categories anyway - it's certainly not possible to predict in which category a package lives. | The key issue is that categories are semantically inadequate. That's no reason to use them improperly. I note you cherry-pick what to respond to. I explained how, without improper use (whatever that is), you just end up with a tug-of-war between herds about which category something should be in. Back hand the herds then. If they want to infight, spank their asses. Herds misbehaving doesn't mean everyone else is going to have a pissing match over the categorization of a pkg however- it shouldn't be used as an arguement _against_ proper categorization, since idiot infighting is a whole other problem. So again, you've *not* given any reasons to avoid sensible package moves. Ah; now you're qualifying. What do you consider to be a sensible package move? I would define it as moves where the package is blatantly in the wrong category (e.g. a voip package being found in the app-text category) rather than moves where the package might be a little more appropriate for one category than another - especially where that judgement is subjective. Arguement over how to categorize I'll gladly stay out of, although one comment- for pkgs that are (at the initial time of adding) one of a kind, creating a category for it's specific flavor doesn't make
Re: [gentoo-dev] New category: net-voip
On Thu, Jul 20, 2006 at 08:41:46PM +0200, Kevin F. Quinn wrote: On Thu, 20 Jul 2006 00:37:47 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: On Wed, 19 Jul 2006 17:15:38 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 19 Jul 2006 08:57:32 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Things that package moves cause: | 1) Dependencies throughout the tree have to be updated And? This isn't a breakage. It is however unnecessary inconvenience for the user, even assuming the support for moves is bug-free. Think you're ignoring that proper categorization *is* useful to the user. One of the costs of that is moving when necessary. My main point is that proper categorisation is subjective. What should be in net-voip for some people, should be in net-im for others (since many packages provide functionality in both areas). Thus whether or not it moves are necessary is subjective. How often does a package lie equally across multiple categories? I think your point (pulling probably fairly close figures out of the head) is relevant to all of 100 or so packages in the tree, out of 11k. Sounds of it, you don't much care for categorizatin- that's fine, please keep in mind some people do find it a net gain to maintain the categorization however. I'm happy with the idea of categorisation in general, I do however think that the categorisation in the tree as it stands is simply inadequate. Examples would be lovely- numerous examples specifically. Please keep in mind the tree holds (as of about 15 hours back) 11,212 packages. Pointing at one or two packages to label all categorization as inadequate won't suffice, going to need to clear at *least* 1% of the tree to back that assertion up. | 3) Binary packages go out-of-date So rebuild them. Binary packages go out of date whenever someone does a version bump too. So your opinion is that it's fine to cause users to rebuild stuff even when the package itself hasn't changed? You're ignoring what fixpackages does. Ever noticed how it's far faster when you don't have buildpkgs enabled? ;) I certainly noticed how much time is lost when fixpackages chunters through built packages to fix stuff up. My usual response to criticism of that sort applies- you know where the src is ;) Doing things *correctly* isn't always the same as doing things *fast*. Throwing correctness bits out in the name of speed is a no go (iow, fixpackages ought to be nonoptional). Again, you may not view categories as useful, but others may. My experience with categories as they stand, is that to find a package whose location I don't already know I have to search all categories anyway - it's certainly not possible to predict in which category a package lives. Not much experience then. Your use scenario above is I'm looking for a package, not I'm trying to find packages in category x. Of course categories don't matter to you in your case- you're not *using* them. What others are talking about how ever is folks who *are* using categories- say to see if any new packages were added to games-strategy. So again, you've *not* given any reasons to avoid sensible package moves. Ah; now you're qualifying. What do you consider to be a sensible package move? I would define it as moves where the package is blatantly in the wrong category (e.g. a voip package being found in the app-text category) rather than moves where the package might be a little more appropriate for one category than another - especially where that judgement is subjective. Arguement over how to categorize I'll gladly stay out of, although one comment- for pkgs that are (at the initial time of adding) one of a kind, creating a category for it's specific flavor doesn't make much sense. How to categorise is critical, if they are to have any meaning to users. Even if a pkg is slightly miscategorized, it still is a fair bit more useful then having a flat namespace. If you want to see if a package is in the tree, do you go straight to it, or do you find yourself doing things like: ls -d /usr/portage/*/packagename* to find it? err... emerge -s packagename pquery packagename paludis -q packagename I'm honestly not really sure what point you're making there. ~harring pgpnCBqQOyGxb.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Thu, 2006-07-20 at 13:24 -0700, Brian Harring wrote: Not much experience then. Your use scenario above is I'm looking for a package, not I'm trying to find packages in category x. Of course categories don't matter to you in your case- you're not *using* them. What others are talking about how ever is folks who *are* using categories- say to see if any new packages were added to games-strategy. Actually, this is a perfect example of categories working properly. After all, if you like to play the occasional RPG, then games-rpg would be where you'd want to look. Sure, some of them are graphical and require X, meaning they *could* be in x11-apps, but that isn't what most people would consider them first. That being said, if you were wanting, say, Neverwinter Nights (nwn), then it is possible you wouldn't know which category it resides in, and need to search for it. However, saying that categories in portage are poorly implemented is pretty much downplaying their usefulness. If someone told me there's a bug in ipw2200, I might not know what that would be. If someone told me there's a bug in net-wireless/ipw2200, I definitely would know that it is some sort of wireless driver/application. Sure, we all know that the categories in portage aren't perfect, but they're pretty good, for most cases. How to categorise is critical, if they are to have any meaning to users. Even if a pkg is slightly miscategorized, it still is a fair bit more useful then having a flat namespace. Agreed. Let's look at something like dhcpcd. It resides in net-misc. Now, without that category, who would know it has *anything* to do with networking (assuming you don't know what DHCP is... :P)? Of course, that isn't the best example, but it does show the point. If you want to see if a package is in the tree, do you go straight to it, or do you find yourself doing things like: ls -d /usr/portage/*/packagename* to find it? err... emerge -s packagename pquery packagename paludis -q packagename I'm honestly not really sure what point you're making there. I find myself first doing emerge $packagename since that *usually* works. ;] After that, I'll resort to some method of searching. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New category: net-voip
On Tue, 18 Jul 2006 21:40:07 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 18 Jul 2006 21:18:22 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Uh, as far as I recall, you've yet to come up with any technical | explanation other than it breaks one of my pet projects... The | gains of consistency and manageability far outweigh the minor | inconvenience. | | Scan back through the -dev archives. We've been over this many times, | in excruciating detail, not that it ever makes any difference. Well that's kinda the point. You haven't. Every time it's just the same vague stuff breaks, without anything genuine value of stuff that isn't someone's pet poorly written toy to back it up. Did you bother to search back through the archives? I know I've posted about this ad nauseum before. Things that package moves cause: 1) Dependencies throughout the tree have to be updated 2) Current installations become inconsistent with respect to the tree 3) Binary packages go out-of-date 4) Increased sync load 5) Loss of history, unless the move is performed server-side (i.e. extra work for infra) fixpackages makes some effort to fix 3, but it's a band-aid solution. For a start, it assumes the binary packages are all present however binary packages may be archived off-line. fixpackages also takes a fair amount of resource to run, resource that end-users don't need to commit if we avoid unnecessary package moves. 4 5 would be mitigated when/if we move to SVN. In my opinion moving packages from one category to another just causes unnecessary disruption to the tree - all relevant dependencies throughout the tree have to be altered, putting current installations out-of-date with respect to it. The key issue is that categories are semantically inadequate. Deciding which category a package fits into is subjective, frequently a package fits into many categories yet the category system insists that a package belong to one and only one category. Usually these big package moves occur when people want to align herds with categories, which is a waste of time - also it's daft as packages can sensibly belong to more than one herd. Unfortunately we see a lot of it in the tree. This week it's packages that have voip functionality that are being moved to net-voip. In six months time it'll be someone else wanting to move all packages with IM functionality into net-im. In herd-speak, these packages could easily belong to both the voip and im herds, should such exist; those providing c++ libraries could also belong to the cpp herd. This is useful, as the maintainers of those herds can each deal with issues in their field. It doesn't matter which category it's in. The only concrete thing categories give us is the ability to have two packages with the same upstream name without having to mangle the upstream name. Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Wed, 19 Jul 2006 08:57:32 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Things that package moves cause: | 1) Dependencies throughout the tree have to be updated And? This isn't a breakage. | 2) Current installations become inconsistent with respect to the tree Uh, current installations become 'inconsistent' whenever anyone changes *anything* in the tree. | 3) Binary packages go out-of-date So rebuild them. Binary packages go out of date whenever someone does a version bump too. | 4) Increased sync load Not really significant in comparison to, say, an arch team keywording a new KDE or Gnome stable. | 5) Loss of history, unless the move is performed server-side (i.e. | extra work for infra) History's in the ChangeLog. | The key issue is that categories are semantically inadequate. That's no reason to use them improperly. So again, you've *not* given any reasons to avoid sensible package moves. This happens every time the topic comes up, and then when taken up on it, certain people quickly resort to accusations of trolling rather than providing any genuine evidence that the drawbacks outweigh the benefits... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New category: net-voip
Hi, the herd of voip packages is constantly growing and according to herdstat -p voip we already have 60 packages in the voip herd. Those are currently in the categories net-misc, net-im, net-libs, dev-libs and media-libs. Most of them would fit perfectly into a new net-voip category. Those are enough packages to allow the creation of a new category. More important than the current packages I think it is to put new packages into the more precise net-voip instead of net-misc/net-im. For example some packages in my overlay [1] maintained by the fellow gentoo users peper and fuoco. Also there is a lot of stuff waiting in stkn's private voip overlay The 47 voip packages in net-misc and net-im should be moved over to the new category definitely, you can get the list with: herdstat -p voip | grep -e net-im -e net-misc From the others I think dev-libs/ilbc-rfc3951 should be moved, too. Any objections, problems with the plan, comments? [1] http://overlays.gentoo.org/svn/dev/genstef/net-im -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Tue, 2006-07-18 at 14:53 +0200, Stefan Schweizer wrote: Hi, the herd of voip packages is constantly growing and according to herdstat -p voip we already have 60 packages in the voip herd. Those are currently in the categories net-misc, net-im, net-libs, dev-libs and media-libs. Most of them would fit perfectly into a new net-voip category. Those are enough packages to allow the creation of a new category. More important than the current packages I think it is to put new packages into the more precise net-voip instead of net-misc/net-im. For example some packages in my overlay [1] maintained by the fellow gentoo users peper and fuoco. Also there is a lot of stuff waiting in stkn's private voip overlay The 47 voip packages in net-misc and net-im should be moved over to the new category definitely, you can get the list with: herdstat -p voip | grep -e net-im -e net-misc From the others I think dev-libs/ilbc-rfc3951 should be moved, too. Creation of a new categories is fine. pkg moves are bad. See the countless other posting on this subject of why pkg moves are bad. Any objections, problems with the plan, comments? Sure I'll step up and say I object to the part of your plan which involves a shitton of pkgmoves. Moving pkgs from existing categories into another category causes numerous problems that portage can't solve as easy as the rest of us might think so please just don't do that part. I've got no objection to the creation of a new category for *new* packages. [1] http://overlays.gentoo.org/svn/dev/genstef/net-im -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Tue, 18 Jul 2006 09:34:37 -0400 Ned Ludd [EMAIL PROTECTED] wrote: | Creation of a new categories is fine. pkg moves are bad. | See the countless other posting on this subject of why pkg | moves are bad. Uh, as far as I recall, you've yet to come up with any technical explanation other than it breaks one of my pet projects... The gains of consistency and manageability far outweigh the minor inconvenience. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Tue, 2006-07-18 at 15:15 +0100, Ciaran McCreesh wrote: On Tue, 18 Jul 2006 09:34:37 -0400 Ned Ludd [EMAIL PROTECTED] wrote: | Creation of a new categories is fine. pkg moves are bad. | See the countless other posting on this subject of why pkg | moves are bad. Uh, as far as I recall, you've yet to come up with any technical explanation other than it breaks one of my pet projects... The gains of consistency and manageability far outweigh the minor inconvenience. There is no consistency for end users when stuff keeps getting shuffled around. Portage still can't get it right. 'fixpackages' does not correct the installed vdb content so the problems extend past any of my pet projects. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Tue, 18 Jul 2006 14:17:30 -0400 Ned Ludd [EMAIL PROTECTED] wrote: | Uh, as far as I recall, you've yet to come up with any technical | explanation other than it breaks one of my pet projects... The | gains of consistency and manageability far outweigh the minor | inconvenience. | | There is no consistency for end users when stuff keeps getting | shuffled around. Uh, end users get consistent and sensible categorising when stuff is properly categorised. It's not exactly consistent to have some foo packages in app-misc and some in app-foo now, is it? | Portage still can't get it right. Specifics? | 'fixpackages' does not correct the installed vdb content so the | problems extend past any of my pet projects. A few people having to rebuild a few binary packages now and again (and incidentally, it'd take you even less time to fix fixpackages) is far less of an issue than keeping an already way too huge tree slightly more manageable. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
