Discussion:
New category: net-voip
(too old to reply)
Stefan Schweizer
2006-07-18 12:53:46 UTC
Permalink
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-***@gentoo.org mailing list
Luca Barbato
2006-07-18 13:25:27 UTC
Permalink
Post by Stefan Schweizer
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
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?
ilbc and other voice codecs should stay in media-libs

Beside that I'm quite happy.

lu
--
Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-***@gentoo.org mailing list
Ned Ludd
2006-07-18 13:34:37 UTC
Permalink
Post by Stefan Schweizer
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
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.
Post by Stefan Schweizer
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.
Post by Stefan Schweizer
[1] http://overlays.gentoo.org/svn/dev/genstef/net-im
--
Ned Ludd <***@gentoo.org>
Gentoo Linux
--
gentoo-***@gentoo.org mailing list
Ciaran McCreesh
2006-07-18 14:15:41 UTC
Permalink
On Tue, 18 Jul 2006 09:34:37 -0400 Ned Ludd <***@gentoo.org> 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-***@gentoo.org mailing list
Ned Ludd
2006-07-18 18:17:30 UTC
Permalink
Post by Ciaran McCreesh
| 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 <***@gentoo.org>
Gentoo Linux
--
gentoo-***@gentoo.org mailing list
Ciaran McCreesh
2006-07-18 20:43:18 UTC
Permalink
On Tue, 18 Jul 2006 14:17:30 -0400 Ned Ludd <***@gentoo.org> 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-***@gentoo.org mailing list
Mike Frysinger
2006-07-18 21:39:49 UTC
Permalink
Post by Ned Ludd
There is no consistency for end users when stuff keeps getting shuffled
around.
i dont see why end users should care ... devs should update the
profile/updates/ files and portage should do the rest
Post by Ned Ludd
Portage still can't get it right. 'fixpackages' does not
correct the installed vdb content
so fix portage ? i dont think this sort of thing should hold up tree
shuffles ...
-mike
Ned Ludd
2006-07-19 15:10:51 UTC
Permalink
Post by Mike Frysinger
Post by Ned Ludd
There is no consistency for end users when stuff keeps getting shuffled
around.
i dont see why end users should care ... devs should update the
profile/updates/ files and portage should do the rest
Every single year quarter after quarter the more updates
that happen the slower portage is becoming.
Care to solve that?
Post by Mike Frysinger
Post by Ned Ludd
Portage still can't get it right. 'fixpackages' does not
correct the installed vdb content
so fix portage ?
I'd rather people not do move unless really necessary.
IE whoops I dumped wireless-tools into app-shells/ where
it clearly does not belong.

But if you are volunteering to fix portage and make
fixpackages not suck then be my guest. I'd welcome not
having to object to package moves. Don't forget the
installed vdb and environment.bz2 have to be rewritten.

My fix would be to remove the ability to do package moves
from portage all together.
Post by Mike Frysinger
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...
emerge history goes half way down the drain.
What do we really gain in the end? Nothing nada..
Just a bunch of heartache for the illusion of easier maintenance.
--
Ned Ludd <***@gentoo.org>
Gentoo Linux
--
gentoo-***@gentoo.org mailing list
Alin Nastac
2006-07-19 16:07:43 UTC
Permalink
Post by Ned Ludd
Every single year quarter after quarter the more updates
that happen the slower portage is becoming.
Care to solve that?
Easy... Just erase updates older than 2 years.
Duncan
2006-07-19 18:22:51 UTC
Permalink
Post by Ned Ludd
Post by Mike Frysinger
Post by Ned Ludd
There is no consistency for end users when stuff keeps getting shuffled
around.
i dont see why end users should care ... devs should update the
profile/updates/ files and portage should do the rest
Every single year quarter after quarter the more updates
that happen the slower portage is becoming.
Care to solve that?
I don't know all of what portage devs did to fixpackages, but with the
2.1.1-pre series now in ~arch anyway (and I /thought/ in 2.1.0, but I may
have been mistaken), it's /so/ much faster, I finally added
FEATURES=fixpackages to make.conf -- along with the FEATURES=buildpkg I've
had there for some time!

Where back with 2.0.5x, it would take forever, starting with moves even
before I had a Gentoo installed (I never did figure out why it couldn't
start from the date of the last one and only do any new fixes, or at
/least/ ignore ones from before my first Gentoo install), now it seems to
skip over them all at once and only slow down when it gets to new
packages. IOW, it seems like they've implemented the timestamp thing and
only update things since then, like I would have thought reasonable to do
all along.

To put it another way, with new portage, fixpackages doesn't seem to be an
issue at all! My first emerge --pretend --update --deep --newuse world
(before it's all memory cached) seems to take longer than fixpackages
does, now. Either they did something very right, or they did something
very wrong and it's skipping everything it should be doing, therefore
explaining the dramatic speed improvements! =8^)

In any case, I used to dread running fixpackages, but it's now simply not
an issue! =8^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
gentoo-***@gentoo.org mailing list
Ciaran McCreesh
2006-07-19 16:10:42 UTC
Permalink
On Wed, 19 Jul 2006 11:10:51 -0400 Ned Ludd <***@gentoo.org> 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-***@gentoo.org mailing list
Ned Ludd
2006-07-22 11:29:21 UTC
Permalink
Post by Ciaran McCreesh
| 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 <***@gentoo.org>
Gentoo Linux
--
gentoo-***@gentoo.org mailing list
Jakub Moc
2006-07-22 11:42:17 UTC
Permalink
Post by Ned Ludd
Post by Ciaran McCreesh
| 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:***@gentoo.org
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E

... still no signature ;)
Simon Stelling
2006-07-22 11:57:56 UTC
Permalink
Post by Jakub Moc
Post by Ned Ludd
Post by Ciaran McCreesh
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-***@gentoo.org mailing list
Stuart Herbert
2006-07-23 11:16:18 UTC
Permalink
Post by Jakub Moc
Post by Ned Ludd
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 ***@gentoo.org
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
--
Kevin F. Quinn
2006-07-18 19:18:22 UTC
Permalink
On Tue, 18 Jul 2006 15:15:41 +0100
Post by Ciaran McCreesh
| 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.
Scan back through the -dev archives. We've been over this many times,
in excruciating detail, not that it ever makes any difference.

BTW genstef - if you insist on doing to package moves, please try to
arrange with infra to retain history (which I was assured can be done
last time I whinged about package moves, however the move has to be
done server-side).
--
Kevin F. Quinn
Ciaran McCreesh
2006-07-18 20:40:07 UTC
Permalink
On Tue, 18 Jul 2006 21:18:22 +0200 "Kevin F. Quinn"
<***@gentoo.org> 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.
--
Ciaran McCreesh
Mail : ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-***@gentoo.org mailing list
Kevin F. Quinn
2006-07-19 06:57:32 UTC
Permalink
On Tue, 18 Jul 2006 21:40:07 +0100
Post by Ciaran McCreesh
On Tue, 18 Jul 2006 21:18:22 +0200 "Kevin F. Quinn"
| > 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
Ned Ludd
2006-07-19 15:17:27 UTC
Permalink
Post by Kevin F. Quinn
On Tue, 18 Jul 2006 21:40:07 +0100
Post by Ciaran McCreesh
On Tue, 18 Jul 2006 21:18:22 +0200 "Kevin F. Quinn"
| > 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.
He just likes to bitch/troll/antagonize. It somehow seems to make him
feel better about himself. It's gotten to the point where I'll respond
at max to one of his mails then ignore all further crap.
--
Ned Ludd <***@gentoo.org>
Gentoo Linux
--
gentoo-***@gentoo.org mailing list
Ciaran McCreesh
2006-07-19 16:15:38 UTC
Permalink
On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
<***@gentoo.org> 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-***@gentoo.org mailing list
Kevin F. Quinn
2006-07-20 07:05:03 UTC
Permalink
On Wed, 19 Jul 2006 17:15:38 +0100
Post by Ciaran McCreesh
On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
| 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.
Post by Ciaran McCreesh
| 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.
Post by Ciaran McCreesh
| 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?
Post by Ciaran McCreesh
| 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.
Post by Ciaran McCreesh
| 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.
Post by Ciaran McCreesh
| 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.
Post by Ciaran McCreesh
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
Brian Harring
2006-07-20 07:37:47 UTC
Permalink
Post by Kevin F. Quinn
On Wed, 19 Jul 2006 17:15:38 +0100
Post by Ciaran McCreesh
On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
| 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.
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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).
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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).
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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.
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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.
Post by Kevin F. Quinn
Post by Ciaran McCreesh
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
Kevin F. Quinn
2006-07-20 18:41:46 UTC
Permalink
On Thu, 20 Jul 2006 00:37:47 -0700
Post by Brian Harring
Post by Kevin F. Quinn
On Wed, 19 Jul 2006 17:15:38 +0100
Post by Ciaran McCreesh
On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
| 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.
Post by Brian Harring
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.
Post by Brian Harring
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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.
Post by Brian Harring
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).
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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.
Post by Brian Harring
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).
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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.
Post by Brian Harring
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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.
Post by Kevin F. Quinn
Post by Ciaran McCreesh
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. 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?
Post by Brian Harring
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
--
Kevin F. Quinn
Brian Harring
2006-07-20 20:24:55 UTC
Permalink
Post by Kevin F. Quinn
On Thu, 20 Jul 2006 00:37:47 -0700
Post by Brian Harring
Post by Kevin F. Quinn
On Wed, 19 Jul 2006 17:15:38 +0100
Post by Ciaran McCreesh
On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
| 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.
Post by Kevin F. Quinn
Post by Brian Harring
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.
Post by Kevin F. Quinn
Post by Brian Harring
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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).
Post by Kevin F. Quinn
Post by Brian Harring
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.
Post by Kevin F. Quinn
Post by Brian Harring
Post by Kevin F. Quinn
Post by Ciaran McCreesh
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.
Post by Kevin F. Quinn
If you want to see if a package is in the tree, do you go
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
Chris Gianelloni
2006-07-20 23:17:24 UTC
Permalink
Post by Brian Harring
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.
Post by Brian Harring
Post by Kevin F. Quinn
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.
Post by Brian Harring
Post by Kevin F. Quinn
If you want to see if a package is in the tree, do you go
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
Diego 'Flameeyes' Pettenò
2006-07-20 23:26:27 UTC
Permalink
Post by Brian Harring
err...
emerge -s <packagename>
pquery <packagename>
paludis -q <packagename>
Or for people into Web 2.0:

http://packages.gentoo.org/search/?sstring=<packagename> (that is what I use
usually, having aliased pgo: to that in konqueror ;) ).
--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
Kevin F. Quinn
2006-07-22 09:45:04 UTC
Permalink
On Thu, 20 Jul 2006 13:24:55 -0700
Post by Brian Harring
Post by Kevin F. Quinn
On Thu, 20 Jul 2006 00:37:47 -0700
Post by Brian Harring
Post by Kevin F. Quinn
On Wed, 19 Jul 2006 17:15:38 +0100
Post by Ciaran McCreesh
On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
| 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?
Post by Brian Harring
Post by Kevin F. Quinn
Post by Brian Harring
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).
Post by Brian Harring
Post by Kevin F. Quinn
Post by Brian Harring
Post by Kevin F. Quinn
Post by Ciaran McCreesh
| 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.
Post by Brian Harring
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.
Post by Brian Harring
Post by Kevin F. Quinn
Post by Brian Harring
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).
Post by Brian Harring
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.
Post by Kevin F. Quinn
Post by Brian Harring
Post by Kevin F. Quinn
Post by Ciaran McCreesh
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.
I'm not arguing for a flat namespace here, I'm arguing that package
moves should be kept to a minimum.
Post by Brian Harring
Post by Kevin F. Quinn
If you want to see if a package is in the tree, do you go
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.
The point is those search commands you list all do the same thing -
find a package from the package name without the category (or at least
can do - I don't know the exact behaviour of pquery or paludis). If you
knew the category you wouldn't need to search for it - however the fact
you have to search for it means the category isn't obvious - and that
means it probably falls naturally into more than one category.
The reason I use 'ls -d' rather than 'emerge -s' is that it's a _lot_
quicker.
--
Kevin F. Quinn
Ciaran McCreesh
2006-07-20 16:27:25 UTC
Permalink
On Thu, 20 Jul 2006 09:05:03 +0200 "Kevin F. Quinn"
<***@gentoo.org> wrote:
| On Wed, 19 Jul 2006 17:15:38 +0100
| Ciaran McCreesh <***@blueyonder.co.uk> wrote:
| > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
| > <***@gentoo.org> 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-***@gentoo.org mailing list
Stuart Herbert
2006-07-21 07:44:35 UTC
Permalink
Post by Kevin F. Quinn
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.
Post by Kevin F. Quinn
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?
Post by Kevin F. Quinn
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).
Post by Kevin F. Quinn
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.
Post by Kevin F. Quinn
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.
Post by Kevin F. Quinn
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.
Post by Kevin F. Quinn
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-***@gentoo.org mailing list
Brian Harring
2006-07-21 08:05:20 UTC
Permalink
Post by Stuart Herbert
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.
BZZZZZZZZ.

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.
Post by Stuart Herbert
Post by Kevin F. Quinn
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
Ciaran McCreesh
2006-07-21 14:49:48 UTC
Permalink
On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring <***@gmail.com>
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-***@gentoo.org mailing list
Kevin F. Quinn
2006-07-22 16:04:10 UTC
Permalink
On Fri, 21 Jul 2006 01:05:20 -0700
Post by Brian Harring
Post by Stuart Herbert
Post by Kevin F. Quinn
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.
Post by Brian Harring
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
Brian Harring
2006-07-22 20:35:08 UTC
Permalink
Post by Ciaran McCreesh
On Fri, 21 Jul 2006 01:05:20 -0700
Post by Brian Harring
Post by Stuart Herbert
Post by Kevin F. Quinn
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.
Post by Brian Harring
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
Kevin F. Quinn
2006-07-24 12:43:10 UTC
Permalink
On Sat, 22 Jul 2006 13:35:08 -0700
Post by Brian Harring
Post by Ciaran McCreesh
On Fri, 21 Jul 2006 01:05:20 -0700
Post by Brian Harring
Post by Stuart Herbert
Post by Kevin F. Quinn
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.
Post by Brian Harring
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.
Post by Brian Harring
Big disadvantage, hence why that approach was ignored last time it
was brought up.
--
Kevin F. Quinn
Ciaran McCreesh
2006-07-22 20:42:07 UTC
Permalink
On Sat, 22 Jul 2006 18:04:10 +0200 "Kevin F. Quinn"
<***@gentoo.org> 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-***@gentoo.org mailing list
Kevin F. Quinn
2006-07-24 12:42:31 UTC
Permalink
On Sat, 22 Jul 2006 21:42:07 +0100
Post by Ciaran McCreesh
On Sat, 22 Jul 2006 18:04:10 +0200 "Kevin F. Quinn"
| 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.
Post by Ciaran McCreesh
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.
Post by Ciaran McCreesh
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.
Post by Ciaran McCreesh
| 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
Stuart Herbert
2006-07-23 11:19:28 UTC
Permalink
Post by Kevin F. Quinn
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 ***@gentoo.org
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
--
Kevin F. Quinn
2006-07-24 12:47:46 UTC
Permalink
On Sun, 23 Jul 2006 12:19:28 +0100
Post by Stuart Herbert
Post by Kevin F. Quinn
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.
Post by Stuart Herbert
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
Brian Harring
2006-07-24 13:23:59 UTC
Permalink
Post by Kevin F. Quinn
On Sun, 23 Jul 2006 12:19:28 +0100
Post by Stuart Herbert
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.
Post by Kevin F. Quinn
As far as
users are concerned, assuming aliases are resolved when being parsed,
$ emerge -p net-im/skype
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.
Post by Kevin F. Quinn
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.
Post by Kevin F. Quinn
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.
Post by Kevin F. Quinn
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
---- 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
Kevin F. Quinn
2006-07-24 15:50:42 UTC
Permalink
On Mon, 24 Jul 2006 06:23:59 -0700
Post by Brian Harring
Post by Kevin F. Quinn
On Sun, 23 Jul 2006 12:19:28 +0100
Post by Stuart Herbert
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.
Post by Brian Harring
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.
Post by Brian Harring
Post by Kevin F. Quinn
As far as
users are concerned, assuming aliases are resolved when being
$ emerge -p net-im/skype
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.
Post by Brian Harring
Post by Kevin F. Quinn
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.
Post by Brian Harring
Post by Kevin F. Quinn
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).
Post by Brian Harring
B) potential of aliasing multiple pkgs to the same cat (fun fun)
Ditto :)
Post by Brian Harring
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)
Huh? If the package name changes, then it's a new package anyway.
I'm assuming that an alias is from C1P to C2 (possibly C1P1 to C2P2
although I don't think that would be useful)
Post by Brian Harring
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)
This is trivial. As I described earlier, all parsing of CPs from
command line, ebuilds or vdb gets aliases resolved to the canonical, or
real, package location. Thereafter everything continues as it does
now - equality tests are performed on the canonical CP so don't have
any trouble.

If we follow the ${PORTDIR}/profiles/alias idea resolving CPs to
canonical form means a simple lookup; hardly heavy duty stuff - and
it could be decided that the alias file always resolves to the real
category location rather than permitting aliasing of aliases (which may
be a good idea anyway).

Some reverse aliasing is needed for purging previous data from the vdb,
something I'd not thought of before, but that's not difficult
(certainly not a show-stopper).
Post by Brian Harring
Fair amount of thorny issues introduced there, for (imo) no real gain.
Post by Kevin F. Quinn
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
---- 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.
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.

I can see an issue where a binpkg of the same package created from a
later date with a different category won't upgrade cleanly on the
standalone system. However package moves as they currently stand don't
upgrade cleanly either, so you haven't lost anything. Similarly with
inconsistencies introduced into the standalone vdb by such actions.


One issue with the single alias config file approach, is that it's easy
for someone to commit a package into an alias location without
realising it (can't be done with the tree CP/alias approach). I don't
know what CVS does when you try to add a directory that previously was
deleted; perhaps that gives an indication. If not, it'd be down to a
repoman check that commits aren't being made to alias locations.


Removals - removing an alias could become problematic, particularly if
the alias location is re-used for another package (which would be the
only good reason for removing an alias, after all). Any existing
references to the alias location would now become real, so these would
need to be fixed up in the tree and in the vdb, binpkgs in much the
same way as package moves require vdb fixups today. This is not
solvable for standalone (i.e. no-tree) machines which get updated from
binpkgs built elsewhere, but again this problem exists for package
moves and isn't solved there either. It's worth thinking about that
issue for tree-present systems; it indicates keeping vdb up-to-date
with current aliasing is necessary. I'll think about that.
--
Kevin F. Quinn
Ciaran McCreesh
2006-07-24 16:30:57 UTC
Permalink
On Mon, 24 Jul 2006 17:50:42 +0200 "Kevin F. Quinn"
<***@gentoo.org> 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-***@gentoo.org mailing list
Jakub Moc
2006-07-24 12:53:29 UTC
Permalink
Post by Stuart Herbert
Post by Kevin F. Quinn
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
Stefan Schweizer
2006-07-18 13:51:14 UTC
Permalink
Post by Ned Ludd
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.
yeah new packages is my primary concern.
Post by Ned Ludd
Post by Stefan Schweizer
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.
I talked with you in IRC about this more. We will do the package moves only
when a bump occurs and will make sure that stable as well as ~arch get an
updated ebuild.

Best regards,
Stefan
--
gentoo-***@gentoo.org mailing list
Ned Ludd
2006-07-18 18:18:37 UTC
Permalink
Post by Stefan Schweizer
Post by Ned Ludd
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.
yeah new packages is my primary concern.
Post by Ned Ludd
Post by Stefan Schweizer
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.
I talked with you in IRC about this more. We will do the package moves only
when a bump occurs and will make sure that stable as well as ~arch get an
updated ebuild.
Sweet/Thanks that works and provides a clear path to upgrade/bump.
--
Ned Ludd <***@gentoo.org>
Gentoo Linux
--
gentoo-***@gentoo.org mailing list
Continue reading on narkive:
Loading...