[gentoo-dev] New category: net-voip

[gentoo-dev] New category: net-voip

[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
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

[Ned Ludd]

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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: New category: net-voip

[Stefan Schweizer]

Ned Ludd 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.
yeah new packages is my primary concern.

>> 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-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category: net-voip

[Ned Ludd]

On Tue, 2006-07-18 at 15:51 +0200, Stefan Schweizer wrote:
> Ned Ludd 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.
> yeah new packages is my primary concern.
> 
> >> 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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Ciaran McCreesh]

On Tue, 18 Jul 2006 09:34:37 -0400 Ned Ludd <solar@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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Ned Ludd]

On Tue, 2006-07-18 at 15:15 +0100, Ciaran McCreesh wrote:
> On Tue, 18 Jul 2006 09:34:37 -0400 Ned Ludd <solar@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.

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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Ciaran McCreesh]

On Tue, 18 Jul 2006 14:17:30 -0400 Ned Ludd <solar@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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Ciaran McCreesh]

On Wed, 19 Jul 2006 11:10:51 -0400 Ned Ludd <solar@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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Ned Ludd]

On Wed, 2006-07-19 at 17:10 +0100, Ciaran McCreesh wrote:
> On Wed, 19 Jul 2006 11:10:51 -0400 Ned Ludd <solar@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.

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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

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:jakub@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   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Simon Stelling]

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

[Stuart Herbert]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

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                                          stuart@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
--


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

[gentoo-dev] Re: New category: net-voip

[Duncan]

Ned Ludd <solar@gentoo.org> posted 1153321851.6243.20.camel@onyx,
excerpted below, on  Wed, 19 Jul 2006 11:10:51 -0400:

> On Tue, 2006-07-18 at 17:39 -0400, Mike Frysinger wrote:
>> On Tuesday 18 July 2006 14:17, Ned Ludd wrote:
>> > 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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Ciaran McCreesh]

On Tue, 18 Jul 2006 21:18:22 +0200 "Kevin F. Quinn"
<kevquinn@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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 3217 bytes --]

On Tue, 18 Jul 2006 21:40:07 +0100
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Tue, 18 Jul 2006 21:18:22 +0200 "Kevin F. Quinn"
> <kevquinn@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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Ciaran McCreesh]

On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
<kevquinn@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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]

On Wed, 19 Jul 2006 17:15:38 +0100
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
> <kevquinn@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.

> | 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 4105 bytes --]

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 <ciaran.mccreesh@blueyonder.co.uk> wrote:
> 
> > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
> > <kevquinn@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.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 5798 bytes --]

On Thu, 20 Jul 2006 00:37:47 -0700
Brian Harring <ferringb@gmail.com> 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 <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > 
> > > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
> > > <kevquinn@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.
> 
> 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
> 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?

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 4786 bytes --]

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 <ferringb@gmail.com> 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 <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > > 
> > > > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
> > > > <kevquinn@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.
> > 
> > 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Thursday 20 July 2006 22:24, Brian Harring wrote:
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 7418 bytes --]

On Thu, 20 Jul 2006 13:24:55 -0700
Brian Harring <ferringb@gmail.com> 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 <ferringb@gmail.com> 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 <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > > > 
> > > > > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
> > > > > <kevquinn@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.
> > > 
> > > 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 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.

I'm not arguing for a flat namespace here, I'm arguing that package
moves should be kept to a minimum.

> > 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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Ciaran McCreesh]

On Thu, 20 Jul 2006 09:05:03 +0200 "Kevin F. Quinn"
<kevquinn@gentoo.org> wrote:
| On Wed, 19 Jul 2006 17:15:38 +0100
| Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:
| > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
| > <kevquinn@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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Stuart Herbert]

On 7/19/06, Kevin F. Quinn <kevquinn@gentoo.org> 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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

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.

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.

> >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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Ciaran McCreesh]

On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring <ferringb@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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

On Fri, 21 Jul 2006 01:05:20 -0700
Brian Harring <ferringb@gmail.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

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 <ferringb@gmail.com> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 3680 bytes --]

On Sat, 22 Jul 2006 13:35:08 -0700
Brian Harring <ferringb@gmail.com> 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 <ferringb@gmail.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Ciaran McCreesh]

On Sat, 22 Jul 2006 18:04:10 +0200 "Kevin F. Quinn"
<kevquinn@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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]

On Sat, 22 Jul 2006 21:42:07 +0100
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Sat, 22 Jul 2006 18:04:10 +0200 "Kevin F. Quinn"
> <kevquinn@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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Stuart Herbert]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

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                                          stuart@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
--


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]

On Sun, 23 Jul 2006 12:19:28 +0100
Stuart Herbert <stuart@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2769 bytes --]

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 <stuart@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 9395 bytes --]

On Mon, 24 Jul 2006 06:23:59 -0700
Brian Harring <ferringb@gmail.com> 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 <stuart@gentoo.org> 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 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)

> 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).

> 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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New category: net-voip

[Ciaran McCreesh]

On Mon, 24 Jul 2006 17:50:42 +0200 "Kevin F. Quinn"
<kevquinn@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-dev@gentoo.org mailing list

Re: [gentoo-dev] New category: net-voip

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]