[gentoo-dev] New category proposal

[gentoo-dev] New category proposal

[Alin Nastac]

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

Hi folks,

I think we should make a new category called app-cellphone containing
the following packages:
  net-dialup/gammu
  net-dialup/gnokii
  net-dialup/wammu
  net-wireless/gnome-phone-manager

Yes, I know. It is a short list, but shouldn't be a category
representative for its content?

Alin


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

Re: [gentoo-dev] New category proposal

[Lars Weiler]

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

* Alin Nastac <mrness@gentoo.org> [05/05/08 16:17 +0300]:
> I think we should make a new category called app-cellphone containing
> the following packages:

Add
app-misc/scmxx
app-misc/gscmxx
app-misc/vmoconv
to the list.  They are all for Siemens phones.

sys-fs/siefs may be another candidate, but it matches better
in sys-fs.  Probably you want to create a cellphone-herd
that takes care of those filesystem-packages, like siefs and
the obex-utilities?

Regards Lars

-- 
Lars Weiler  <pylon@gentoo.org>  +49-171-1963258
Gentoo Linux PowerPC    : Manager and Release Engineer
Gentoo Infrastructure   : CVS Administrator
Gentoo Public Relations : Assistance for Europe

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

[gentoo-dev] Re: New category proposal

[R Hill]

Alin Nastac wrote:
> Hi folks,
> 
> I think we should make a new category called app-cellphone containing
> the following packages:
>   net-dialup/gammu
>   net-dialup/gnokii
>   net-dialup/wammu
>   net-wireless/gnome-phone-manager
> 
> Yes, I know. It is a short list, but shouldn't be a category
> representative for its content?

net-wireless/obexftp
net-misc/sms
net-misc/linuxsms
net-misc/ksms
net-misc/gsmlib
net-misc/esms
media-sound/bemused
media-plugins/xmms-btexmms
kde-misc/kmobiletools	}
kde-base/kandy		} these could probably stay in kde
app-pda/x70talk
app-pda/bitpim
app-misc/ringtonetools

this doesn't include anything like VOIP of course.  btw i think 
"cellphone" is an Americanism.  i worked for AT&T Wireless before they 
were bought by Cingular and the term "cellphone" was discouraged for 
that reason.  maybe just app-phone?

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal, [gentoo-dev]

[Alin Nastac]

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

R Hill wrote:

>
>
> this doesn't include anything like VOIP of course.  btw i think
> "cellphone" is an Americanism.  i worked for AT&T Wireless before they
> were bought by Cingular and the term "cellphone" was discouraged for
> that reason.  maybe just app-phone?

hmm... I think it should include "cell" or "mobile" in one way or the
other - "phone" is just too generic.
I am not a native English speaker (duh, what a surprise :)), so I'm open
to suggestions.

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

Re: [gentoo-dev] Re: New category proposal, [gentoo-dev]

[Mike Frysinger]

On Sunday 08 May 2005 04:46 pm, Alin Nastac wrote:
> R Hill wrote:
> > this doesn't include anything like VOIP of course.  btw i think
> > "cellphone" is an Americanism.  i worked for AT&T Wireless before they
> > were bought by Cingular and the term "cellphone" was discouraged for
> > that reason.  maybe just app-phone?
>
> hmm... I think it should include "cell" or "mobile" in one way or the
> other - "phone" is just too generic.

app-mobile sounds good to me ... then just use metadata.xml to include a 
'fuller' description :P
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev]

[Henrik Brix Andersen]

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

On Sun, 2005-05-08 at 19:53 -0400, Mike Frysinger wrote:
> app-mobile sounds good to me ... then just use metadata.xml to include a 
> 'fuller' description :P

Please don't use app-mobile as it may be confused with mobile computing,
not mobile phones.

Any reason why these packages can not go into app-pda? Most modern
mobile phones can be considered a handheld computer (and many of them
can be thought of as either a phone with integrated PDA - or a PDA with
integrated phone).

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Linux

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

Re: [gentoo-dev]

[Alin Nastac]

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

Henrik Brix Andersen wrote:

>On Sun, 2005-05-08 at 19:53 -0400, Mike Frysinger wrote:
>  
>
>>app-mobile sounds good to me ... then just use metadata.xml to include a 
>>'fuller' description :P
>>    
>>
>
>Please don't use app-mobile as it may be confused with mobile computing,
>not mobile phones.
>
>Any reason why these packages can not go into app-pda? Most modern
>mobile phones can be considered a handheld computer (and many of them
>can be thought of as either a phone with integrated PDA - or a PDA with
>integrated phone).
>
>
>  
>
I think I will call it app-mobphone.

Please explain what do you understand as "mobile computing". You keep
using this term.
>From what I see in herds.xml, mobile == "Wireless (802.11a/b/g,
bluetooth, etc) related items"

Mobile phones are far from PDAs. I don't see anything you can't do with
a PDA (since it _is_ a computer).
Compared to them, _normal_ mobile phones are very limited devices.


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

Re: [gentoo-dev]

[Henrik Brix Andersen]

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

On Mon, 2005-05-09 at 16:21 +0300, Alin Nastac wrote:
> Please explain what do you understand as "mobile computing". You keep
> using this term.
> >From what I see in herds.xml, mobile == "Wireless (802.11a/b/g,
> bluetooth, etc) related items"

http://en.wikipedia.org/wiki/Mobile_computing

> Mobile phones are far from PDAs. I don't see anything you can't do with
> a PDA (since it _is_ a computer).
> Compared to them, _normal_ mobile phones are very limited devices.

My last two mobile phones (Motorola A920 and Motorola E1000) are
symbian-based hand-helds, and they act like a PDA - but I still can't do
the same stuff with my PDA as I can with a PC.

I suggested app-pda because of the metadata.xml description:

        The app-pda category contains software for working with personal
        digital assistants or hand-held computers.

As I've said, I think most modern mobile phones can be considered being
a PDA/hand-held computer.

./Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Linux


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

Re: [gentoo-dev] New category proposal

[Alin Nastac]

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

Henrik Brix Andersen wrote:

>On Mon, 2005-05-09 at 16:21 +0300, Alin Nastac wrote:
>  
>
>>Please explain what do you understand as "mobile computing". You keep
>>using this term.
>>>From what I see in herds.xml, mobile == "Wireless (802.11a/b/g,
>>bluetooth, etc) related items"
>>    
>>
>
>http://en.wikipedia.org/wiki/Mobile_computing
>  
>
Then it is true... mobile phone stuff classifies as mobile computing. It
should be your playground, not mine.

>  
>
>>Mobile phones are far from PDAs. I don't see anything you can't do with
>>a PDA (since it _is_ a computer).
>>Compared to them, _normal_ mobile phones are very limited devices.
>>    
>>
>
>My last two mobile phones (Motorola A920 and Motorola E1000) are
>symbian-based hand-helds, and they act like a PDA - but I still can't do
>the same stuff with my PDA as I can with a PC.
>
>  
>
Well, my wife has a Erricson T610, which is far from being as advanced
as yours.

>I suggested app-pda because of the metadata.xml description:
>
>        The app-pda category contains software for working with personal
>        digital assistants or hand-held computers.
>
>As I've said, I think most modern mobile phones can be considered being
>a PDA/hand-held computer.
>
>  
>
Category names should help users in searching their favorite
applications. I doubt that anyone will look in app-pda for gammu.

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

Re: [gentoo-dev] New category proposal

[Henrik Brix Andersen]

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

On Mon, 2005-05-09 at 17:01 +0300, Alin Nastac wrote:
> Then it is true... mobile phone stuff classifies as mobile computing. It
> should be your playground, not mine.

PDAs also classify as mobile computing, yet the mobile herd doesn't
handle PDA related applications either - as you saw from the description
in herds.xml. These are handled by the app-pda herd.

If you would like to become a member of the mobile herd and take care of
all mobile phone related packages, feel free. As it is now the mobile
herd is not staffed to handle that kind of packages.

You could also start a new mobile phone herd similar to the app-pda herd
with the sole purpose of taking care of mobile phone related packages.

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Linux

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

Re: [gentoo-dev] New category proposal

[Peter Cech]

On Mon, May 09, 2005 at 05:01:41PM +0300, Alin Nastac wrote:
> Henrik Brix Andersen wrote:
> 
> >On Mon, 2005-05-09 at 16:21 +0300, Alin Nastac wrote:
> >  
> >
> >>Please explain what do you understand as "mobile computing". You keep
> >>using this term.
> >>>From what I see in herds.xml, mobile == "Wireless (802.11a/b/g,
> >>bluetooth, etc) related items"
> >>    
> >>
> >
> >http://en.wikipedia.org/wiki/Mobile_computing
> >  
> >
> Then it is true... mobile phone stuff classifies as mobile computing. It
> should be your playground, not mine.

Even if I associate the term "mobile" with mobile phones, I would think
that category app-mobile has more to do with laptops. When I see it in a
computer I decode it as "mobile computer", not "mobile phone".

Regards,

Peter Cech
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev]

[Sami Samhuri]

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

* On Mon May-09-2005 at 03:34:36 PM +0200, Henrik Brix Andersen said:
> On Mon, 2005-05-09 at 16:21 +0300, Alin Nastac wrote:
[...]
> > Mobile phones are far from PDAs. I don't see anything you can't do with
> > a PDA (since it _is_ a computer).
> > Compared to them, _normal_ mobile phones are very limited devices.
> 
> My last two mobile phones (Motorola A920 and Motorola E1000) are
> symbian-based hand-helds, and they act like a PDA - but I still can't do
> the same stuff with my PDA as I can with a PC.

I have a symbian phone as well (Nokia 3595, at least I'm pretty sure
Nokia's run symbian) but it does not act like a PDA. Luckily I also have
a PDA (i-Mate PDA2K, aka O2 XDA IIs, MDA III, and so on...) which acts
as a phone. Needless to say these devices are far from similar.

> I suggested app-pda because of the metadata.xml description:
> 
>         The app-pda category contains software for working with personal
>         digital assistants or hand-held computers.
> 
> As I've said, I think most modern mobile phones can be considered being
> a PDA/hand-held computer.

The latest and greatest phones can almost be considered PDAs, I agree.
But they are not the norm yet. I mean, my phone can run Java
applications and has GPRS but that's about as far as it goes. My PDA,
well it has everything from BlueTooth and 802.11b to GPRS, GSM (850,
900, 1800, 1900) as well as an internal 128M flash memory and a 512M SD
card in the expansion slot. It even has a slide-out keyboard.  This
thing is more powerful than most PCs 10 years ago. They are converging,
but PDAs are advancing at an astonishing rate since they're geared
towards power users and geeks. Phones aren't moving as fast since for
the average person they just want a phone that makes and receives calls.
Does the average person use Gentoo? Probably not, but I still think they
are very different beasts for now and should be kept separate.

I am aware that mobile phones outside of North America are much more
advanced (in general) so perhaps this is the cause of this little
disagreement. I don't have a really strong opinion either way, but I
thought I'd throw in my user's perspective.

-- 
Sami Samhuri

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

Re: [gentoo-dev] Re: New category proposal, [gentoo-dev]

[W.Kenworthy]

In Oz, cellphone is only used in american movies, here they are called
"mobile phones" (formal), "mobiles" (common usage) and "mob" when
written (e.g., Mob: 0419...)

There's also the upcoming "cell" processor architecture that may clash
in the future.

How about app-mobphone or app-mobilephone or perhaps
app-mobilephoneutils or some variant of?

BillK


On Sun, 2005-05-08 at 11:57 -0600, R Hill wrote:
> Alin Nastac wrote:
> > Hi folks,
> > 
> > I think we should make a new category called app-cellphone containing
> > the following packages:
> >   net-dialup/gammu
> >   net-dialup/gnokii
> >   net-dialup/wammu
> >   net-wireless/gnome-phone-manager
> > 
> > Yes, I know. It is a short list, but shouldn't be a category
> > representative for its content?
> 
> net-wireless/obexftp
> net-misc/sms
> net-misc/linuxsms
> net-misc/ksms
> net-misc/gsmlib
> net-misc/esms
> media-sound/bemused
> media-plugins/xmms-btexmms
> kde-misc/kmobiletools	}
> kde-base/kandy		} these could probably stay in kde
> app-pda/x70talk
> app-pda/bitpim
> app-misc/ringtonetools
> 
> this doesn't include anything like VOIP of course.  btw i think 
> "cellphone" is an Americanism.  i worked for AT&T Wireless before they 
> were bought by Cingular and the term "cellphone" was discouraged for 
> that reason.  maybe just app-phone?
> 
> --de.
> 

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal, [gentoo-dev]

[Collins Richey]

On 5/8/05, W.Kenworthy <billk@iinet.net.au> wrote:
> In Oz, cellphone is only used in american movies, here they are called
> "mobile phones" (formal), "mobiles" (common usage) and "mob" when
> written (e.g., Mob: 0419...)
> 
> There's also the upcoming "cell" processor architecture that may clash
> in the future.
> 
> How about app-mobphone or app-mobilephone or perhaps
> app-mobilephoneutils or some variant of?
> 

You could always borrow from the Germans and call it app-handy.

-- 
 Collins
       When I saw the Iraqi people voting three weeks ago, 8 million of them, 
       it was the start of a new Arab world.... The Berlin Wall has fallen. 
               - Lebanese Druze leader Walid Jumblatt

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal, [gentoo-dev]

[Lars Weiler]

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

* Collins Richey <crichey@gmail.com> [05/05/08 17:01 -0600]:
> You could always borrow from the Germans and call it app-handy.

Yeah!  That's pure Denglisch :)

And while we are on it, add all packages for presentations
into an "app-beamer" group ;-)

Well, back on topic.  Some of the suggested packages will
not work with GSM-phones only, but also with DECT-phones.
And if we include VoIP-Applications, they can finally get
into a better home than net-misc... app-telephony?
phone-mobile/phone-net?

Regards, Lars

-- 
Lars Weiler  <pylon@gentoo.org>  +49-171-1963258
Gentoo Linux PowerPC    : Manager and Release Engineer
Gentoo Infrastructure   : CVS Administrator
Gentoo Public Relations : Assistance for Europe

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

Re: [gentoo-dev] Re: New category proposal, [gentoo-dev]

[Georgi Georgiev]

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

maillog: 09/05/2005-01:50:04(+0200): Lars Weiler types
> * Collins Richey <crichey@gmail.com> [05/05/08 17:01 -0600]:
> > You could always borrow from the Germans and call it app-handy.
> 
> Yeah!  That's pure Denglisch :)
> 
> And while we are on it, add all packages for presentations
> into an "app-beamer" group ;-)
> 
> Well, back on topic.  Some of the suggested packages will
> not work with GSM-phones only, but also with DECT-phones.
> And if we include VoIP-Applications, they can finally get
> into a better home than net-misc... app-telephony?
> phone-mobile/phone-net?

Would it be inappropriate to start bitching (again) about a flat tree
where each package can go in multiple categories?

-- 
(*   Georgi Georgiev   (* No small art is it to sleep: it is necessary (*
*)    chutz@gg3.net    *) for that purpose to keep awake all day. --   *)
(*  +81(90)2877-8845   (* Nietzsche                                    (*

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

Re: [gentoo-dev] Re: New category proposal

[Aron Griffis]

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

Georgi Georgiev wrote:	[Sun May 08 2005, 08:19:20PM EDT]
> Would it be inappropriate to start bitching (again) about a flat
> tree where each package can go in multiple categories?

That's something I'd love to see eventually...  I mean the flat tree,
not the complaining ;-)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] Re: New category proposal

[Martin Schlemmer]

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

On Mon, 2005-05-09 at 13:07 -0400, Aron Griffis wrote:
> Georgi Georgiev wrote:	[Sun May 08 2005, 08:19:20PM EDT]
> > Would it be inappropriate to start bitching (again) about a flat
> > tree where each package can go in multiple categories?
> 
> That's something I'd love to see eventually...  I mean the flat tree,
> not the complaining ;-)
> 

Problem with flat tree, is the search times might then suck even more,
as last I heard, too many dirs/files in one directory have a huge speed
penalty.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


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

[gentoo-dev] Re: Re: New category proposal

[Duncan]

Martin Schlemmer posted <1115715727.25756.8.camel@nosferatu.lan>,
excerpted below,  on Tue, 10 May 2005 11:02:07 +0200:

> Problem with flat tree, is the search times might then suck even more, as
> last I heard, too many dirs/files in one directory have a huge speed
> penalty.

Yeah, sure, for ext2/3, but all those small files would suck big time in
ext2/3 anyway.  Reiserfs doesn't have either issue, and should be perfect
for portage trees, even for those who still think the reliability isn't
there (I've been /very/ happy with it here, since the data=ordered
default went into the kernel for reiserfs, even when I had defective
memory and was hard-locking fairly frequently due to that), because
portage trees are a simple sync away from replacing anything lost. 

I never remember which one it is, but either jfs or xfs has packed files
as a feature as well, IIRC, so the small file sizes works, altho I believe
it'd still have issues with high file-count dirs.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Martin Schlemmer posted <1115715727.25756.8.camel@nosferatu.lan>,
> excerpted below,  on Tue, 10 May 2005 11:02:07 +0200:
> 
> 
>>Problem with flat tree, is the search times might then suck even more, as
>>last I heard, too many dirs/files in one directory have a huge speed
>>penalty.
> 
> 
> Yeah, sure, for ext2/3, but all those small files would suck big time in
> ext2/3 anyway.  Reiserfs doesn't have either issue, and should be perfect
> for portage trees, even for those who still think the reliability isn't
> there (I've been /very/ happy with it here, since the data=ordered
> default went into the kernel for reiserfs, even when I had defective
> memory and was hard-locking fairly frequently due to that), because
> portage trees are a simple sync away from replacing anything lost. 
> 
> I never remember which one it is, but either jfs or xfs has packed files
> as a feature as well, IIRC, so the small file sizes works, altho I believe
> it'd still have issues with high file-count dirs.
> 
I'll be the first alt-arch person to scream, Reiser isn't stable on more
than half the arch's we support, and forcing users to go to one
filesystem just to get decent speed on portage tree searches is silly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQoDNu2zglR5RwbyYAQIVVxAAlC4Yctbrz/HnnVCtxn2o6IpgeEQ5yRmu
0IxSV65iBGJ0MutqO6uhOpWeg50YQEHB121BMkHkdkxOllD+oyxN43MVDHH/9PLu
NMPBCHfAi2N6IT8h/563lONEFMw/SYGIT3fCQBn8+pc9IgsHdHkVAo49Az9ahR/2
tjKHSrb7ERQE/bFOnE9jmm4bYX9Gdub30J96/3QrMo5KORH1ncmShD1VNf+awmpC
vrE/r7JypU9DzmS3tdWuwm7QYCD9jWRDYLscEjrl546uKhTpHDaLerFQ1MNn/p1I
Hb8eX4bmBdI58NLtH0Wui+s6fZ6zlBYjKZhdT+mTObYgLTr3hn31rnKPpC46guE6
36/qmQT53YMXd9/QMiHVsAkIfujFMO3/eSt6P8wJ3Y+Y7BYjntHJq9RScXWiYCsW
idQL9IWAUObNeQvACyukGlMNm1e8QlxdkE+pukYnR2M07xNPJgPcG7eqlAgObohW
KBJ+Yr1wpRm4M9DAfzvGgB1EsWuwRO7G0izEadZlCzVjXGc0XH56HFFPqnEOFmxy
SJrYqOJSbDAFjUl/Cb1I4zW5g/BuSENIoc5f4M+vmxYXGxTGGX/pLhuXchauh+QP
Ux1zwjuSnAek5yDiKaiuiAUaKFO/ug5AsLd0MpkjGEJ4qCSqZ7jObntIlbiaxpyH
JSNBRj9hrbs=
=uJKJ
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Stephen Bennett]

On Tue, 2005-05-10 at 11:05 -0400, Alec Warner wrote:
> I'll be the first alt-arch person to scream, Reiser isn't stable on more
> than half the arch's we support, and forcing users to go to one
> filesystem just to get decent speed on portage tree searches is silly.

Besides which, as of latested released kernels Reiser still doesn't have
working extended attributes, so SELinux systems can't mount it.
Apparently there's a patch kicking around, but forcing people to patch
kernels themselves is even sillier.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: New category proposal

[Duncan]

Stephen Bennett posted <1115739418.24940.5.camel@localhost>, excerpted
below,  on Tue, 10 May 2005 16:36:57 +0100:

> On Tue, 2005-05-10 at 11:05 -0400, Alec Warner wrote:
>> I'll be the first alt-arch person to scream, Reiser isn't stable on more
>> than half the arch's we support, and forcing users to go to one
>> filesystem just to get decent speed on portage tree searches is silly.
> 
> Besides which, as of latested released kernels Reiser still doesn't have
> working extended attributes, so SELinux systems can't mount it. Apparently
> there's a patch kicking around, but forcing people to patch kernels
> themselves is even sillier.

Well, the latter anyway shouldn't be a big issue.  That's what Gentoo
ships patched kernels for, right?  ... And as for not stable on various
archs, that's what open source is for, right?  (Leastwise I always see
complaints from others and have complained myself about that being one of
the problems with Java, not available in decently recent form on many
archs because it's not open for those motivated enough to make it work,
when those that /have/ the source refuse to do so, to do so themselves. 
Said as I (im)patiently wait for reiser4 to stabilize on amd64, because I
regrettably don't have the skill set required to help get it there. =8^\)

Anyway, I wasn't necessarily arguing for a flat portage dir tree, but
simply pointing out that the problem of too many file/dir entries in a dir
has a known and open source solution, therefore, that problem by itself
isn't that big a deal.  In practice, the flat-logical tree, organized by
letter, would probably be easier to work with, because regardless of the
ability of technology to handle the disk layout efficiently, humanity
doesn't scale so fast, and more than a few hundred entries simply gets
hard for the humans to work with, even if the file system has no problem
with it.  The file system problem may be solved, but the human problem is
something else entirely (and tab completion doesn't work for
/everything/). Thus, really what I'm saying is don't deal with the
small, already solved stuff, when there's far larger unsolved problems --
if it's taken to be a flat dir layout, anyway -- that could be mentioned.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: New category proposal

[Stephen P. Becker]

> Well, the latter anyway shouldn't be a big issue.  That's what Gentoo
> ships patched kernels for, right?  ... And as for not stable on various
> archs, that's what open source is for, right?

By not stable on the various arches, he means it doesn't even work on
some (sparc for example).  Also, you should ask the upstream sparc and
mips kernel developers what they think of ricerfs sometime.  You'll
either A) get laughed at mercilessly, B) get flamed out of the building,
or C) all of the above.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: New category proposal

[Stephen Bennett]

On Tue, 2005-05-10 at 10:25 -0700, Duncan wrote:
> Well, the latter anyway shouldn't be a big issue.  That's what Gentoo
> ships patched kernels for, right?  ... And as for not stable on various
> archs, that's what open source is for, right?

What's what open source is for? Spending your time fixing other people's
broken code so that it works on your arch, when there's a rock-solid
alternative that already works better and has done for years? As for
proper xattrs, it's another of those cases where it's not worth fixing
reiser when ext3 (or xfs, of course) works perfectly well.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal

[Martin Schlemmer]

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

On Mon, 2005-05-09 at 13:07 -0400, Aron Griffis wrote:
> Georgi Georgiev wrote:	[Sun May 08 2005, 08:19:20PM EDT]
> > Would it be inappropriate to start bitching (again) about a flat
> > tree where each package can go in multiple categories?
> 
> That's something I'd love to see eventually...  I mean the flat tree,
> not the complaining ;-)
> 

Problem with flat tree, is the search times might then suck even more,
as last I heard, too many dirs/files in one directory have a huge speed
penalty.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


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

Re: [gentoo-dev] Re: New category proposal

[Georgi Georgiev]

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

maillog: 10/05/2005-11:28:21(+0200): Martin Schlemmer types
> On Mon, 2005-05-09 at 13:07 -0400, Aron Griffis wrote:
> > Georgi Georgiev wrote:	[Sun May 08 2005, 08:19:20PM EDT]
> > > Would it be inappropriate to start bitching (again) about a flat
> > > tree where each package can go in multiple categories?
> > 
> > That's something I'd love to see eventually...  I mean the flat tree,
> > not the complaining ;-)
> > 
> 
> Problem with flat tree, is the search times might then suck even more,
> as last I heard, too many dirs/files in one directory have a huge speed
> penalty.

The flat tree does not imply a flat hierarchy on disk. Files and
directories can still be organized in a more optimized manner. For
example -- put each package in a directory of its first letter. Maybe
even two letters if you think that the winner 'g' with 736 packages is
too many.

This is only true when the portage tree is stored on a filesystem. I
recall some effort being made in making portage support reading the
portage tree from a zipfile, so we may eventually see some other
backends that would not suffer from this problem.

If that's the only problem you're having with the flat tree, should I
consider you a supporter?

-- 
 /   Georgi Georgiev    / The Golden Rule of Arts and Sciences: He who  /
\     chutz@gg3.net    \  has the gold makes the rules.                \
 /  +81(90)2877-8845    /                                               /

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

Re: [gentoo-dev] Re: New category proposal

[Brian Harring]

On Tue, May 10, 2005 at 08:04:04PM +0900, Georgi Georgiev wrote:
> maillog: 10/05/2005-11:28:21(+0200): Martin Schlemmer types
> > On Mon, 2005-05-09 at 13:07 -0400, Aron Griffis wrote:
> > > Georgi Georgiev wrote:	[Sun May 08 2005, 08:19:20PM EDT]
> > > > Would it be inappropriate to start bitching (again) about a flat
> > > > tree where each package can go in multiple categories?
> > > 
> > > That's something I'd love to see eventually...  I mean the flat tree,
> > > not the complaining ;-)
> > > 
> > 
> > Problem with flat tree, is the search times might then suck even more,
> > as last I heard, too many dirs/files in one directory have a huge speed
> > penalty.
> 
> The flat tree does not imply a flat hierarchy on disk. Files and
> directories can still be organized in a more optimized manner. For
> example -- put each package in a directory of its first letter. Maybe
> even two letters if you think that the winner 'g' with 736 packages is
> too many.
This would basically require a totally seperate rsync module for newer 
portage versions that would handle it.  Or portage would have to 
support both, which (frankly) is something of a no go; it's too 
fricking ugly imo.

Beyond that, drop the optimized manner in reference to speed; 
addressed below.  Optimized for human readability?  not so sure, 
digging through debian's directory structure to dig out certain files 
has always drove me slightly insane while doing so...


> This is only true when the portage tree is stored on a filesystem. I
> recall some effort being made in making portage support reading the
> portage tree from a zipfile, so we may eventually see some other
> backends that would not suffer from this problem.
Down the line, viable (should be able to basically go nuts in terms of 
how you store the tree, locally, remotely, etc).  Now?  eh, tiz a ways 
off.

Regarding speed comments about look up in the tree, frankly it's a bit 
minor imo.  Initial installed package scan is a heavier hit (it's 
required for even an emerge --help).  The bits in this thread about 
using xyz fs for the tree are trying to address the effects, not the 
cause of potentially slow cp_list/cp_all lookups; if the tree were 
marked as frozen (non-modifiable, iow users don't modify an ebuild 
here and there), and portage had frozen support (working on it), you 
could work directly from the cache instead, which would be a bit 
faster (at the very least, less syscalls, (open|close|read)dir, 
stat'ing, etc).

The speed portion of the arg in other words, I don't think is valid.  
Better to focus on what benefits the poor human who has to go digging 
through the tree manually, then try to make portage go faster via it 
w/ dir structuring/underlying fs.

Re: having a package claimed by multiple categories... eh.  yeah, 
that's a bit valid although I'd think it's either A) an indiciation 
our categories need to be adjusted a bit, or B) (hopefully) a rare 
case. :)

My 2 cents, at least.
~Brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal

[Georgi Georgiev]

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

maillog: 10/05/2005-22:30:56(-0500): Brian Harring types
> Re: having a package claimed by multiple categories... eh.  yeah, 
> that's a bit valid although I'd think it's either A) an indiciation 
> our categories need to be adjusted a bit, or B) (hopefully) a rare 
> case. :)

No, no, please not A). 8-O

As to whether the categories are good or not... think about it. If they
were good, would we still be seeing packages moving around the tree?
That's why I think that multiple categories are a necessity. Unless of
course, packages stop getting moved around and Gentoo can gurantee that
all packages will stay at their current location.

What about the Mozilla suite. What in the world is it doing in
www-client? After all, the Mozilla suite is
- a www browser (www-client)
- a mail client (mail-client)
- a calendar
- an html composer
- an irc client (net-irc)

Might as well go to net-misc :-/

My personal reasons to start the topic about the flat tree:

- I hate the moves of packages between categories which causes enough
  problems as it is. I also find the arguments of where to put what
  pointless. Who cares if it is mail-client/mutt or net-mail/mutt as
  long as it stays in one place and is accessible by its name "mutt". If
  you think that mail-client is more descriptive than net-mail, then add
  "keywords" (for those who hate the idea of multiple categories) to the
  metadata of each package and let emerge -s search by keyword. Does
  "mutt" not belong to net-mail? It does, but mail-client is better.
  Still, that is no reason to remove its relation to "net-mail".  Cache
  the keyword information to make the search as fast as possible and
  you're done with the searchability part. You can now safely forget
  about this thing called "categories" as they become irrelevant, and
  hopefully never move another package.

- I also hate being unable to find exactly the package that I need right
  away. I want to check mutt's ebuild... cd /usr/portage/... what next?
  Is it at the same place that I remember it was the last time I
  checked? Do I *have* to know what category it belongs to? Of course I
  can do "cd /usr/portage/*/mutt", but shell completion on the mutt part
  won't work on this one. Mutt's not quite the example for the necessity
  of completions, but it gets worse with longer names like
  mozilla-firefox-bin.

- Personal overlays. I think this a point that's clear enough. Gentoo
  devs may have scripts that keep the tree in sync after the
  loved-by-all move of a package, but that doesn't apply to us, mere
  mortals.

Disclaimer: I did not intend to be offensive even if at times I seem to.
I was not being sarcastic either.

-- 
/\   Georgi Georgiev   /\ I'm not an Iranian!! I voted for Dianne      /\
\/    chutz@gg3.net    \/ Feinstein!!                                  \/
/\  +81(90)2877-8845   /\                                              /\

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

Re: [gentoo-dev] Re: New category proposal

[Brian Harring]

On Wed, May 11, 2005 at 01:27:46PM +0900, Georgi Georgiev wrote:
> As to whether the categories are good or not... think about it. If they
> were good, would we still be seeing packages moving around the tree?
> That's why I think that multiple categories are a necessity. Unless of
> course, packages stop getting moved around and Gentoo can gurantee that
> all packages will stay at their current location.

Keep in mind the tree is in constant flux, new packages added, 
packages removed, etc.  Of course there will be a bit of 
reorganization, unless we add every possible category under the sun 
(even then, $10 on some weird esoteric category being requested 
shortly after such a change) ;)
Point I'm getting at is that the need for a better groupping occurs 
depending on the packages being added. 

One thing that just clicked in the skull on why flat-tree has issues; 
currently it's possible to have a package with the same name, yet a
differing category (app-vim/sudo vs app-admin/sudo).

Since our tree layout is based upon category, if you tried shifting 
the focus of it to packages_in anyway_, you would explicitly disallow 
same name packages, different category.  Doesn't matter how you 
structure the tree, if you do lookup into the tree based on package, 
not category, you disallow same named packages.


> What about the Mozilla suite. What in the world is it doing in
> www-client? After all, the Mozilla suite is
> - a www browser (www-client)
> - a mail client (mail-client)
> - a calendar
> - an html composer
> - an irc client (net-irc)
> 
> Might as well go to net-misc :-/

This is why I commented that there are exceptions, question is if the 
exceptions are annoying enough the level of change required, is 
implemented (I posit no, but that's cause I see issues w/ the 
resulting namespace, and am lazy).


> - I hate the moves of packages between categories which causes enough
>   problems as it is. I also find the arguments of where to put what
>   pointless. Who cares if it is mail-client/mutt or net-mail/mutt as
>   long as it stays in one place and is accessible by its name "mutt". If
>   you think that mail-client is more descriptive than net-mail,
The category labelling of it matters for those who go groking for an 
app to use, but don't know the possibilities.  Example: "well, lets 
see what mail clients exist, and pick one of 'em for use based upon 
the description, since I've had it with my current mail client"...


>    then add
>   "keywords" (for those who hate the idea of multiple categories) to the
>   metadata of each package and let emerge -s search by keyword. Does
>   "mutt" not belong to net-mail? It does, but mail-client is better.
>   Still, that is no reason to remove its relation to "net-mail".  Cache
>   the keyword information to make the search as fast as possible and
>   you're done with the searchability part. You can now safely forget
>   about this thing called "categories" as they become irrelevant, and
>   hopefully never move another package.
> - I also hate being unable to find exactly the package that I need right
>   away. I want to check mutt's ebuild... cd /usr/portage/... what next?
>   Is it at the same place that I remember it was the last time I
>   checked? Do I *have* to know what category it belongs to? Of course I
>   can do "cd /usr/portage/*/mutt", but shell completion on the mutt part
>   won't work on this one. Mutt's not quite the example for the necessity
>   of completions, but it gets worse with longer names like
>   mozilla-firefox-bin.

Re: yeah, it's fricking annoying, agreed.  I'd state a faster tool is preferable, 
rather then a reorganization (imo).

See above about why flattening the tree so it's package-centric rather 
then category-centric has issues.  The consequence is that you 
have to start moving category specific metadata into the package 
name when valid conflicts occur- the sudo/vim example above, would 
require vim-sudo or vim-plugins-sudo.

Debian does this, they (ab|)use a flattened namespace.  I strongly 
dislike it, even compared to the consequences of our N category 
approach.  Granted they lack (afaik) category data, but the 
consequences of flattening the namespace still stands imo. :)

So... next possibility is doing the additional categories via 
extra metadata (xyz is *primarily* cat a, but also is cat b and c).  
Complaints over speed would easily triple if this was added; if you 
don't find a package within a (on disk dir) categories namespace, you 
have to walk the metadata for *all* ebuilds to verify that there isn't 
another package that has allegance to that category.  Yes, this can be 
cached, but it is a pita and is added complexity (in other words, 
gains needs to offset this extra cost).

> - Personal overlays. I think this a point that's clear enough. Gentoo
>   devs may have scripts that keep the tree in sync after the
>   loved-by-all move of a package, but that doesn't apply to us, mere
>   mortals.

Got me there.  Would need an active translation layer, cpv was this, 
is now that, to make overlays a bit friendlier.

Note I'm commenting on -overlays-, not -repositories- (bmg's stuff is 
effectively a repository).  Translation bit might apply there also, 
but that's getting into a terminology discussion... :)

> Disclaimer: I did not intend to be offensive even if at times I seem to.
> I was not being sarcastic either.

Sarcasm goes with the territory, wouldn't worry- you're making your 
points, not relying on sarcasm/offense to be your points.
The former just adds to the fun. ;)
~Brian

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: New category proposal

[Duncan]

Brian Harring posted <20050511050920.GC17034@exodus.wit.org>, excerpted
below,  on Wed, 11 May 2005 00:09:20 -0500:

> One thing that just clicked in the skull on why flat-tree has issues;
> currently it's possible to have a package with the same name, yet a
> differing category (app-vim/sudo vs app-admin/sudo).
> 
> Since our tree layout is based upon category, if you tried shifting the
> focus of it to packages_in anyway_, you would explicitly disallow same
> name packages, different category.  Doesn't matter how you structure the
> tree, if you do lookup into the tree based on package, not category, you
> disallow same named packages.

While I'm not a flat tree supporter per se, duplicate packages are IMO a
bad thing in any case, for two reasons.

1) Human.  It's frustrating to do emerge sudo and have it tell you to
specify, when there's only /one/ "normal" sudo.  The /other/ sudo should
be vim-sudo or whatever, as you mention later.

2) Bin-pkgs.  As currently structured, we have a de-facto "flat" bin-pkgs
layout anyway, since the tree is simply a bunch of symlinks pointing to
the $PKGDIR/All dir that /all/ the packages land in.  Clashing packages is
NOT a good thing, as I'm sure you are aware.  /Something/ really needs to
be done about this one.  Any possible light at the end of the tunnel here?

BTW, it'd be very handy to have "slotted" bin-pkgs as well, "slotted" as
in allowing me to do things like test a gcc4 created package, without
erasing my gcc-3.4 created bin-pkg, in case something doesn't work, and
without having to remember to manually copy/move the existing bin-pkg
first to keep that backup.  A feature to enable some arbitrary identifier
in the binpkg name, or an arbitrary string as a binpkg subdir path
fragment, would be very helpful.  Something like FEATURES=binpkg-name then
enabling a BINPKG-NAME=gcc4, to then either create a $PKGDIR/gcc4 subtree,
or $PKGDIR/All/package-version.gcc4.tbz2 type package and appropriate
symlink.  One could then just remember to change the $BINPKG-NAME entry in
make.conf whenever one runs gcc-config, or whenever one triggers whatever
switch and desires a corresponding binpkg-slot change.  Anything like this
in the works?  Should I file an enhancement bug?  Maybe the ability is
there already and I just don't know it, as with the very cool make.conf
"source" feature I saw mentioned on the amd64 list?

BTW2, does the "." shortcut work in make.conf?  I can envision a make.conf
that's simply a half dozen or so lines of "source
/etc/portage/make.network.conf", ". /etc/portage/make.useflags.conf", etc.
Is that documented anywhere, yet?  When (version) was it introduced?

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Brian Harring]

On Tue, May 10, 2005 at 10:59:42PM -0700, Duncan wrote:
> > Since our tree layout is based upon category, if you tried shifting the
> > focus of it to packages_in anyway_, you would explicitly disallow same
> > name packages, different category.  Doesn't matter how you structure the
> > tree, if you do lookup into the tree based on package, not category, you
> > disallow same named packages.
> 
> While I'm not a flat tree supporter per se, duplicate packages are IMO a
> bad thing in any case, for two reasons.
> 
> 1) Human.  It's frustrating to do emerge sudo and have it tell you to
> specify, when there's only /one/ "normal" sudo.  The /other/ sudo should
> be vim-sudo or whatever, as you mention later.

Yeah, it's usually something I hit everytime I build a new box- it is 
valid though, and I think it makes sense.  app-vim/sudo 
makes sense in the context of the category, just the same as 
app-admin/sudo does.  While frustrating, I still posit it's not a huge 
problem.  The actual number of conflicts I haven't looked up, but I 
would expect it's not huge in comparison to the # of packages we have.

> 2) Bin-pkgs.  As currently structured, we have a de-facto "flat" bin-pkgs
> layout anyway, since the tree is simply a bunch of symlinks pointing to
> the $PKGDIR/All dir that /all/ the packages land in.  Clashing packages is
> NOT a good thing, as I'm sure you are aware.  /Something/ really needs to
> be done about this one.  Any possible light at the end of the tunnel here?

Binpkgs implementation sucks.
The current "slap em all in a dir and abuse symlinks" 
bit can be dodged down the line.


> BTW, it'd be very handy to have "slotted" bin-pkgs as well, "slotted" as
> in allowing me to do things like test a gcc4 created package, without
> erasing my gcc-3.4 created bin-pkg, in case something doesn't work, and
> without having to remember to manually copy/move the existing bin-pkg
> first to keep that backup.  A feature to enable some arbitrary identifier
> in the binpkg name, or an arbitrary string as a binpkg subdir path
> fragment, would be very helpful.  Something like FEATURES=binpkg-name then
> enabling a BINPKG-NAME=gcc4, to then either create a $PKGDIR/gcc4 subtree,
> or $PKGDIR/All/package-version.gcc4.tbz2 type package and appropriate
> symlink.  One could then just remember to change the $BINPKG-NAME entry in
> make.conf whenever one runs gcc-config, or whenever one triggers whatever
> switch and desires a corresponding binpkg-slot change.  Anything like this
> in the works?
Umm.  yes?
Cleanup of stuff in general is in the works, including (done when it's 
done) binpkg handling being tweaked, which may or may not cover the 
huge-ass block of requests above :)

>  Should I file an enhancement bug?  Maybe the ability is
> there already and I just don't know it, as with the very cool make.conf
> "source" feature I saw mentioned on the amd64 list?
> 
> BTW2, does the "." shortcut work in make.conf?  I can envision a make.conf
> that's simply a half dozen or so lines of "source
> /etc/portage/make.network.conf", ". /etc/portage/make.useflags.conf", etc.
> Is that documented anywhere, yet?  When (version) was it introduced?

Source works, not sure when it was added, but it's not source in the 
sense of bash's source; it just makes the make.conf 
interpretter/parser (it's not bash based) go and read whatever it's 
pointed at.

2.0.51.19 has it at least, possibly earlier.  '.' however doesn't fly, 
from what I can see source wise at least.
~brian
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: New category proposal

[Duncan]

Brian Harring posted <20050511065023.GE17034@exodus.wit.org>, excerpted
below,  on Wed, 11 May 2005 01:50:23 -0500:

> Umm.  yes?
> Cleanup of stuff in general is in the works, including (done when it's
> done) binpkg handling being tweaked, which may or may not cover the
> huge-ass block of requests above :)

I see I didn't effectively convey what I wanted, then, if the description
is a "huge-ass block of requests".  =8^)  Let's see if I can reword it a
bit more effectively...

What I had in mind (and tried to describe), was a /single/ (if large)
/general/ feature, call it FEATURE=binpkg-name, to be combined with a
second parameter enabled by that feature, BINPKG-NAME=<whatever>. 
<whatever> would then either be a) created as a subdir of the existing
$PKGDIR, or b) appended to the name of the package in the existing dir,
preferably creating a double-extension, as in bash-3.0-r11.gcc4.tbz2, if
(as in my example, the reason I'd presently find this useful)
BINPKG-NAME="gcc4".

Thus, for this specific use, I'd either a) have a $PKGDIR/gcc4 subtree in
addition to the normal $PKGDIR subtree (which would be equivalent to
BINPKG-NAME=""), or b) have individual packages such as
bash-3.0-r11.gcc4.tbz2, as well as possibly having the normal
bash-3.0-r11.tbz2, with the feature or BINPKG-NAME var unset.

However, as envisioned, the feature would be generalized enough to allow
all sorts of other uses as well, perhaps for MULTILIB (MULTIAPP??) folks,
a separate 32-bit and 64-bit copy of the same package, use of the same
general $PKGDIR location with different archs due to the possible subtrees
(or subnames), or for any other sort of testing or local use where
creating a binpkg that doesn't overwrite a previous version might be
useful.  The key here is that the feature as implemented would be general
enough to allow all sorts of local flexibility as to how it was used.

So far, I've only discussed portage binpkg creation.  Use of those
additional binpkg subtrees/subnames could remain manual only, requiring
the user/admin to shuffle the desired binpkg back into the default
location, and still be quite useful.  Alternatively, and probably when
the second half of implementation is complete, portage would account for
the feature, and if it was on read the var and draw from the appropriate
subtree/subname (a or b options above) as configured.

/IF/ that makes any more sense...  Single feature, implemented as a toggle
feature with a var pointer, thus generalizing the use.

If the above were to be implemented, gcc-config could then possibly take
advantage of it, appending to the local installation set BINPKG-NAME var 
for experimental versions of gcc.  If the feature was set, it would then
automatically create its own experimental binpkgs which wouldn't overwrite
existing versions.  If the feature was unset, setting BINPKG-NAME
wouldn't have any effect.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: New category proposal

[Duncan]

Duncan posted <pan.2005.05.11.10.03.13.603585@cox.net>, excerpted below, 
on Wed, 11 May 2005 03:03:14 -0700:

> I see I didn't effectively convey what I wanted, then, if the description
> is a "huge-ass block of requests".  =8^)  Let's see if I can reword it a
> bit more effectively...
> 
> What I had in mind (and tried to describe), was a /single/ (if large)
> /general/ feature, call it FEATURE=binpkg-name, to be combined with a
> second parameter enabled by that feature, BINPKG-NAME=<whatever>.

Never mind...  It seems the feature I wanted is already there, only I
wasn't thinking broadly enough.  Georgi Georgiev pointed it out...

My proposal would have allowed a bit more automation, but at FAR more
complexity.  Better leaving well enough alone.

Portage's flexibility in sysadmin customizability continues to amaze me. 
It really /is/ an awesome system Gentoo has built, when one thinks about
it. =8^)  Sometimes in the minutia of discussion we (I, anyway) forget
just how awesomely flexible the existing toolset actually is! 
Definitely "standing on the shoulders of giants", we owe drobbins and
indeed, the FBSD ports system from which he got a lot of inspiration, a
great deal of gratitude.  That's not forgetting current developers, of
course.  =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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Georgi Georgiev]

maillog: 10/05/2005-22:59:42(-0700): Duncan types
> BTW, it'd be very handy to have "slotted" bin-pkgs as well, "slotted" as
> in allowing me to do things like test a gcc4 created package, without
> erasing my gcc-3.4 created bin-pkg, in case something doesn't work, and
> without having to remember to manually copy/move the existing bin-pkg
> first to keep that backup.  A feature to enable some arbitrary identifier
> in the binpkg name, or an arbitrary string as a binpkg subdir path
> fragment, would be very helpful.  Something like FEATURES=binpkg-name then
> enabling a BINPKG-NAME=gcc4, to then either create a $PKGDIR/gcc4 subtree,
> or $PKGDIR/All/package-version.gcc4.tbz2 type package and appropriate
> symlink.  One could then just remember to change the $BINPKG-NAME entry in
> make.conf whenever one runs gcc-config, or whenever one triggers whatever
> switch and desires a corresponding binpkg-slot change.  Anything like this
> in the works?

PKGDIR=/usr/portage-pkg/gcc4 emerge -B app-admin/sudo

That ought to do what you want it to do. But then, portage will be
unable to untar-uncompress-sed/awk/whatever-tar-compress (refering to
"fixpackages" by its full name here) the binary packages in your custom
location if a package in there jumps categories.  Wow, I managed to get
back on topic :)

-- 
 /   Georgi Georgiev    / What's all this brouhaha?                     /
\     chutz@gg3.net    \                                               \
 /  +81(90)2877-8845    /                                               /
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Georgi Georgiev]

maillog: 11/05/2005-16:10:48(+0900): Георги Георгиев types
> maillog: 10/05/2005-22:59:42(-0700): Duncan types
> > BTW, it'd be very handy to have "slotted" bin-pkgs as well, "slotted" as
> > in allowing me to do things like test a gcc4 created package, without
> > erasing my gcc-3.4 created bin-pkg, in case something doesn't work, and
> > without having to remember to manually copy/move the existing bin-pkg
> > first to keep that backup.  A feature to enable some arbitrary identifier
> > in the binpkg name, or an arbitrary string as a binpkg subdir path
> > fragment, would be very helpful.  Something like FEATURES=binpkg-name then
> > enabling a BINPKG-NAME=gcc4, to then either create a $PKGDIR/gcc4 subtree,
> > or $PKGDIR/All/package-version.gcc4.tbz2 type package and appropriate
> > symlink.  One could then just remember to change the $BINPKG-NAME entry in
> > make.conf whenever one runs gcc-config, or whenever one triggers whatever
> > switch and desires a corresponding binpkg-slot change.  Anything like this
> > in the works?
> 
> PKGDIR=/usr/portage-pkg/gcc4 emerge -B app-admin/sudo
> 
> That ought to do what you want it to do. But then, portage will be
> unable to untar-uncompress-sed/awk/whatever-tar-compress

Uh, seems I was wrong here. Looking at portage.py there is no mention of
compress/uncomrpess. Only a copy stuff away, copy it back. I did have
the feeling that it used to be that way but, well, I guess I was
mistaken.

> (refering to "fixpackages" by its full name here) the binary packages

- referring -- screw them misspelled HTTP headers >:|

> in your custom location if a package in there jumps categories.  Wow,
> I managed to get back on topic :)

-- 
 /   Georgi Georgiev    / Life would be so much easier if we could      /
\     chutz@gg3.net    \  just look at the source code. -- Dave Olson  \
 /  +81(90)2877-8845    /                                               /
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: New category proposal

[Duncan]

Georgi Georgiev posted <20050511071048.GA2445@ols-dell.gg3.net>, excerpted
below,  on Wed, 11 May 2005 16:10:48 +0900:

> PKGDIR=/usr/portage-pkg/gcc4 emerge -B app-admin/sudo
> 
> That ought to do what you want it to do. But then, portage will be unable
> to untar-uncompress-sed/awk/whatever-tar-compress (refering to
> "fixpackages" by its full name here) the binary packages in your custom
> location if a package in there jumps categories.  Wow, I managed to get
> back on topic :)

Hmm...  Yes, I'm beginning to see this, now that the discussion seems to
be widening my viewpoint a bit.  One of those "Duh, why didn't I see that
before?" moments on my part. <g>

I'm not sure as to the uncompress issue (as you followup with), but simply
setting a different PKGDIR location when I run gcc-config should do what I
wanted, and I can then simply switch back to the old tree if necessary
with a quick reset of PKGDIR.

Thanks for pointing that out!

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Ciaran McCreesh]

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

On Tue, 10 May 2005 22:59:42 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
| 1) Human.  It's frustrating to do emerge sudo and have it tell you to
| specify, when there's only /one/ "normal" sudo.  The /other/ sudo
| should be vim-sudo or whatever, as you mention later.

Silly. Then you'd *always* have to give the full name of a package when
merging, in effect... emerge sys-devel-gcc rather than emerge gcc with
emerge sys-devel/gcc as a fallback, for example.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Re: Re: New category proposal

[Georgi Georgiev]

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

maillog: 11/05/2005-16:41:37(+0100): Ciaran McCreesh types
> On Tue, 10 May 2005 22:59:42 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
> | 1) Human.  It's frustrating to do emerge sudo and have it tell you to
> | specify, when there's only /one/ "normal" sudo.  The /other/ sudo
> | should be vim-sudo or whatever, as you mention later.
> 
> Silly. Then you'd *always* have to give the full name of a package when
> merging, in effect... emerge sys-devel-gcc rather than emerge gcc with
> emerge sys-devel/gcc as a fallback, for example.

But we are only arguing of getting the categories (partially) in the
package name only where there is a necessity. The example with sudo is
with app-admin/sudo being strictly sudo, and app-vim/sudo being
vim-sudo. So we keep the current names except for those that clash, and
even there only change as little as possible.

-- 
 >   Georgi Georgiev    > To be who one is, is not to be someone        >
<     chutz@gg3.net    <  else.                                        <
 >  +81(90)2877-8845    >                                               >

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

Re: [gentoo-dev] Re: Re: New category proposal

[Ciaran McCreesh]

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

On Thu, 12 May 2005 02:21:28 +0900 Georgi Georgiev <chutz@gg3.net>
wrote:
| maillog: 11/05/2005-16:41:37(+0100): Ciaran McCreesh types
| > On Tue, 10 May 2005 22:59:42 -0700 Duncan <1i5t5.duncan@cox.net>
| > wrote:
| > | 1) Human.  It's frustrating to do emerge sudo and have it tell you
| > | to specify, when there's only /one/ "normal" sudo.  The /other/
| > | sudo should be vim-sudo or whatever, as you mention later.
| > 
| > Silly. Then you'd *always* have to give the full name of a package
| > when merging, in effect... emerge sys-devel-gcc rather than emerge
| > gcc with emerge sys-devel/gcc as a fallback, for example.
| 
| But we are only arguing of getting the categories (partially) in the
| package name only where there is a necessity. The example with sudo is
| with app-admin/sudo being strictly sudo, and app-vim/sudo being
| vim-sudo. So we keep the current names except for those that clash,
| and even there only change as little as possible.

So we end up not using upstream naming, leading to major hassle with
tarballs, major user confusion and inconsistent naming (why are some vim
things vim- and others not?). Bad! Now that portage *tells* you when you
need to be more specific, there's no problem with name matches.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Re: Re: New category proposal

[Georgi Georgiev]

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

maillog: 11/05/2005-19:06:37(+0100): Ciaran McCreesh types
> So we end up not using upstream naming, leading to major hassle with
> tarballs, major user confusion and inconsistent naming (why are some vim
> things vim- and others not?). Bad! Now that portage *tells* you when you
> need to be more specific, there's no problem with name matches.

I'll agree with you here. There doesn't seem to be an easy way to decide
what package will get a part of a category in its name. I was going to
propose a "plugins/extensions for an application get the name of the app
prepended + dash", but there would surely be others that will prove me
wrong.

I am giving up on arguing a point that involves too much effort for too
little gain. So, considering that the flat-naming is not feasible (I
cannot counter some of the point that were made against it, the above
being one of them) I'd like to stop shooting out ideas and restate the
problem that I think needs to be solved:

How do we prevent a current category/package combination like
net-wireless/gnome-phone-manager from becoming something else like
app-cellphone/gnome-phone-manager?

More preceisely, what I'd like to see, in order of preference, is

- that package in my overlay that has net-wireless/gnome-phone-manager
  in its *DEPENDs to work for as long as needed
- the net-wireless/gnome-phone-manager that I have in my overlay to
  work for as long as needed
- my net-wireless/gnome-phone-manager binary packages to work without
  having to be "fixpackage"d
- the location of the ebuilds for net-wireless/gnome-phone-manager to
  stay in the same physical path on my filesystem

-- 
\/   Georgi Georgiev   \/ Weiner's Law of Libraries: There are no      \/
/\    chutz@gg3.net    /\ answers, only cross references.              /\
\/  +81(90)2877-8845   \/                                              \/

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

Re: [gentoo-dev] Re: Re: New category proposal

[Ciaran McCreesh]

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

On Thu, 12 May 2005 04:01:17 +0900 Georgi Georgiev <chutz@gg3.net>
wrote:
| How do we prevent a current category/package combination like
| net-wireless/gnome-phone-manager from becoming something else like
| app-cellphone/gnome-phone-manager?

Two options:

* Smarter updates handling by portage. For example, maybe it could
realise that the package in question has been moved, and automatically
do the update (along with a QA notice: assumed package move blah). This
would also help for those unfortunate times when we don't manage to do a
huge package move in under the required half an hour.

* Unique ID strings for packages, zynot style. Messy as hell though,
DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
the same kind of ring to it...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Re: Re: New category proposal

[Brian Harring]

On Wed, May 11, 2005 at 08:10:03PM +0100, Ciaran McCreesh wrote:
> On Thu, 12 May 2005 04:01:17 +0900 Georgi Georgiev <chutz@gg3.net>
> wrote:
> | How do we prevent a current category/package combination like
> | net-wireless/gnome-phone-manager from becoming something else like
> | app-cellphone/gnome-phone-manager?
> 
> Two options:
> 
> * Smarter updates handling by portage. For example, maybe it could
> realise that the package in question has been moved, and automatically
> do the update (along with a QA notice: assumed package move blah). This
> would also help for those unfortunate times when we don't manage to do a
> huge package move in under the required half an hour.
That requires _active_ translation of deps.  The current 
search/replace type hackery is binpkg/vdb based, doesn't do jack for 
ebuilds that still point at the old location.

> * Unique ID strings for packages, zynot style. Messy as hell though,
> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
> the same kind of ring to it...
Actually... iirc, at least internally the unique 'key' for a cpv 
that's being kicked around collapses cat/pkg/slot/use.  Not much for 
tacking on more metadata, since the unique key/id bit above still 
requires active translation of deps as they're encountered.

No really easy way to dodge that, nor does it sound like stable 
material. (my opinion mind you).
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Stroller]

On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
>
> * Unique ID strings for packages, zynot style. Messy as hell though,
> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
> the same kind of ring to it...

Maybe I'm just a messy person, but I really like this. It prevents 
upstream naming collisions & opens multiple categories per package 
completely. Mr Harring will hate it, but the rest of us will use 
`esearch -o "%p\n" "" | grep -e category -e keyword`.

Stroller.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Patrick Lauer]

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

On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
> >
> > * Unique ID strings for packages, zynot style. Messy as hell though,
> > DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
> > the same kind of ring to it...
> 
> Maybe I'm just a messy person, but I really like this.
So does Microsoft. The registry has many entries where 128bit (?)
object-IDs are used. Very interesting to debug. 
>  It prevents upstream naming collisions 
But reduces readability for humans to zero. We don't want that.

> & opens multiple categories per package 
> completely. Mr Harring will hate it, 
At least you haven't tried to optimize it all by using XML ...
> but the rest of us will use 
> `esearch -o "%p\n" "" | grep -e category -e keyword`.
*head explodes*
No.

As much as I like the idea of a "better" portage, a binary obfuscation
won't help. It might make portage more resilient to one kind of problem,
but forget debugging then.

Patrick

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

Re: [gentoo-dev] Re: Re: New category proposal

[Stroller]

On May 12, 2005, at 10:11 am, Patrick Lauer wrote:
> On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
>> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
>>>
>>> * Unique ID strings for packages, zynot style. Messy as hell though,
>>> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't 
>>> have
>>> the same kind of ring to it...
>>
>> Maybe I'm just a messy person, but I really like this.
> So does Microsoft. The registry has many entries where 128bit (?)
> object-IDs are used. Very interesting to debug.

I'm going to ignore that. This thread started because the current 
category/name naming convention causes interesting conditions. I 
appreciate that generally Microsoft Are Not Our Favourite Software 
Company, but giving them as an example doesn't inherently make unique 
IDs bad, and 128-bit ones are not necessary in this case.

Also, before I start, I'd like to say that I know I'm not qualified to 
advocate this as a serious suggestion for adoption by Gentoo, so I'm 
just explaining _why I like it_.

>>  It prevents upstream naming collisions
> But reduces readability for humans to zero. We don't want that.

Humans are used to dealing with indexes - we remember phone numbers 
easily, and if we're looking up several things in a large volume, then 
we're used to using bookmarks or noting down page numbers. A six figure 
decimal packageID allows for a million packages in the Portage tree 
(and I'm assuming versions will be separate, anyway), a five figure hex 
ID would allow far more.

Yes, arbitrary unique IDs would require an index tool to access ebuild 
name / category data, but surely there is little choice if 
naming-collisions are to be avoided and multiple categories are 
desired? Surely any human-focused naming convention will cause 
collisions and introduce potential for confusion? The current 
categories divide collisions into separate spaces, but they don't solve 
the problem of foo-player being eligible for both the media-CDplayers 
and audio-mp3rippers categories.

> At least you haven't tried to optimize it all by using XML ...
>> but the rest of us will use
>> `esearch -o "%p\n" "" | grep -e category -e keyword`.
> *head explodes*
> No.

That's the first time I used that command, but it only took me two 
minutes to look up & test. Since a dedicated index tool would clearly 
be required, I'm sure it would have better & more useful syntax. 
Currently I assume that Mr Harring searches for all the applications in 
a category by typing `ls -d /usr/portage/app-category/*` - wouldn't it 
be easier to use `esearch --category country`. Not only would it list 
them all, but multiple categories per package would also allow those to 
be shown that might debatably be categorised as "western".

> ...It might make portage more resilient to one kind of problem,
> but forget debugging then.

Do we have 65000 unique packages in the tree? Would a four figure hex 
"part number" be that hard to remember when you're debugging package 
names?

Again: I know I'm not qualified to advocate this as a serious 
suggestion for adoption by Gentoo, so I'm just explaining _why I like 
it_.

Stroller.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stroller wrote:
> 
> On May 12, 2005, at 10:11 am, Patrick Lauer wrote:
> 
>> On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
>>
>>> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
>>>
>>>>
>>>> * Unique ID strings for packages, zynot style. Messy as hell though,
>>>> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
>>>> the same kind of ring to it...
> 
> 
> I'm going to ignore that. This thread started because the current
> category/name naming convention causes interesting conditions. I
> appreciate that generally Microsoft Are Not Our Favourite Software
> Company, but giving them as an example doesn't inherently make unique
> IDs bad, and 128-bit ones are not necessary in this case.
> 
  32-bit (unsigned) should be plenty ;)
> 
>>>  It prevents upstream naming collisions
>>
>> But reduces readability for humans to zero. We don't want that.
> 
> 
> Humans are used to dealing with indexes - we remember phone numbers
> easily, and if we're looking up several things in a large volume, then
> we're used to using bookmarks or noting down page numbers. A six figure
> decimal packageID allows for a million packages in the Portage tree (and
> I'm assuming versions will be separate, anyway), a five figure hex ID
> would allow far more.
>  
>> At least you haven't tried to optimize it all by using XML ...
>>
>>> but the rest of us will use
>>> `esearch -o "%p\n" "" | grep -e category -e keyword`.
>>
>> *head explodes*
>> No.
  I think there are a few points that are at the core of this.
	A.  Categories are metadata.  Not many people like doing this,
especially since you are sorting by a particular metadata that isn't
unique in all cases ( or shouldn't be ).  If people want to sort by
something else, it too should be unique, hence the GUID crap above.
This might kill off names ( do we not want a package have 2 names, or 2
packages having the same name? ).

	B.  Users don't care how the data is stored, they will create/use tools
to search through it.  I think this is much different than the
developer's view.  As a user, if I am looking for a package I'll use
emerge -s or p.g.o.  I don't go diving into the tree unless I'm looking
for an ebuild and I doubt that many users actually go ebuild diving.
This creates issues where developers need to get to ebuilds to check out
issues, and users want fast searching.  One is condusive to human
readability, the other is to computer readability.

	Is human readability worth it here, and is there a storage mechanism
that gives us both?  Certainly the current system works, albeit with
some limitations that some people do not like.  IMHO I think the flat
tree sucks too, but I haven't put much thought into any other storage
mechanism.  Certainly it would be nice if one machine held the database
on a SQL server and each client just made queries, although it would be
much slower :)

	I should also note that ripping categories out of CPV's means a lot of
work on internals; I think it's worth it to spec things out now since a
lot of other stuff is being gutted anyway.

- -Antarus

> Stroller.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQoNDzGzglR5RwbyYAQJaVQ//ZsFJzSkm35bo87SAwUqtWKjOvOn6CUph
2vdOfnjIjJQkhgeew8RMp/f+TiKuCT8t0WVtTKsS5mLeno2WXkqetbfVayfsT29L
kMqp42LUDPBEHe+aOMn8TlKjCvPpNow4TWecFEoaV6MF4sutxyP3+cg6Noay7hiF
mvGahADLpuENNaLpmy0ETs6oh4UeReI6PBl6QrO46uj9kL3HnFxPRncp+52Q0KHh
44uoqcGu4PYF5YfTHqyA71Ibg9SPKPUGxHbs53ISVmhWRWuRs6l+3N7aXyap5ChV
iBMsAzns0xMAuV25BoPTmdyQSyJBAXfXCtAWJ0PcFRx5lnMvVJ95McXjjeINbG60
dWJQ1q1CKeOIVnm6JScwtkELm1yXIKnQ8wqpSevC+xrNUwJCth/g6pHvSPZhw9ng
R6nTpwd8DWwUJ7j90L7Aggf2vB2+f/u2c03er120PKiAMJIJtLXHJlLrkGH8/MkT
F1fol4TF4i4sLXJ+kceoOFHEgT70kmQXpdzTMfhcm3BAIBxTDGkjWS5+U+3K3wCj
3fgxm/28B9b396cdoXWDOgV9C1kEe1IkC+GKe6CmFqIiP70Ov4eGgj3ejSabY5YV
OWiPKMeLPjZtL5H4359k6S2U42zJI9BJUoJgFP9iQhhMA8Io+GLKVwwv+5Jd+V9l
BoHjO7tPWmw=
=nJ6R
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Brian Harring]

On Thu, May 12, 2005 at 08:01:23PM +0100, Stroller wrote:
> >>>* Unique ID strings for packages, zynot style. Messy as hell though,
> >>>DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't 
> >>>have
> >>>the same kind of ring to it...
> >>
> >>Maybe I'm just a messy person, but I really like this.
> >So does Microsoft. The registry has many entries where 128bit (?)
> >object-IDs are used. Very interesting to debug.
> 
> I'm going to ignore that. This thread started because the current 
> category/name naming convention causes interesting conditions. I 
> appreciate that generally Microsoft Are Not Our Favourite Software 
> Company, but giving them as an example doesn't inherently make unique 
> IDs bad, and 128-bit ones are not necessary in this case.
I suspect his point was that a 128-bit ID is holy hell on frail 
humans, versus a category/package string (which isn't).


> >> It prevents upstream naming collisions
> >But reduces readability for humans to zero. We don't want that.
> 
> Humans are used to dealing with indexes - we remember phone numbers 
> easily
Majority of the population don't have 1000+ phone numbers memorized 
though (which is roughly what we're talking about here for the package 
equiv).

> and if we're looking up several things in a large volume, then 
> we're used to using bookmarks or noting down page numbers. A six figure 
> decimal packageID allows for a million packages in the Portage tree 
> (and I'm assuming versions will be separate, anyway), a five figure hex 
> ID would allow far more.
Heh, counter example.  Consider cell phones, people search for numbers 
based upon arbitrary names associated with the digits (one could view 
our category/package bit as the same).

> Yes, arbitrary unique IDs would require an index tool to access ebuild 
> name / category data, but surely there is little choice if 
> naming-collisions are to be avoided and multiple categories are 
> desired? Surely any human-focused naming convention will cause 
> collisions and introduce potential for confusion? The current 
> categories divide collisions into separate spaces, but they don't solve 
> the problem of foo-player being eligible for both the media-CDplayers 
> and audio-mp3rippers categories.
One problem, still need to resort to a human readable representation 
for specifying depends.  Stating DEPEND="mpeg? ( \d{16} ) \d{16}" 
would be hell on devs.  An automated approach could be leveled, but 
would need a *really* good reason to explain the loss of DEPEND 
readability via an editor.

> >At least you haven't tried to optimize it all by using XML ...
Antarus, was that you who tried the cache backend using xml? ;)

> >>but the rest of us will use
> >>`esearch -o "%p\n" "" | grep -e category -e keyword`.
> >*head explodes*
> >No.
> That's the first time I used that command, but it only took me two 
> minutes to look up & test. Since a dedicated index tool would clearly 
> be required, I'm sure it would have better & more useful syntax. 
> Currently I assume that Mr Harring searches for all the applications in 
> a category by typing `ls -d /usr/portage/app-category/*` - wouldn't it 
> be easier to use `esearch --category country`. Not only would it list 
> them all, but multiple categories per package would also allow those to 
> be shown that might debatably be categorised as "western".
actually... I use emerge -s @category
emerge's speed is an issue granted, but not a reason to restructure 
(the speed issue isn't related to it, it's initialization overhead of 
import portage).

> >...It might make portage more resilient to one kind of problem,
> >but forget debugging then.
> 
> Do we have 65000 unique packages in the tree? Would a four figure hex 
> "part number" be that hard to remember when you're debugging package 
> names?
Yeah, imo.  What gain is there in having to memorize 1623 is openssh, 
just so I can comprehend the DEPEND string when glancing over an 
ebuild?

> Again: I know I'm not qualified to advocate this as a serious 
> suggestion for adoption by Gentoo, so I'm just explaining _why I like 
> it_.
content is what matters, not the speaker or his/her qualifications :)
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New category proposal

[Jan Kundrát]

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

Stroller wrote:
>>>> * Unique ID strings for packages, zynot style. Messy as hell though,
>>>> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
>>>> the same kind of ring to it...
[snip]
> I'm going to ignore that. This thread started because the current
> category/name naming convention causes interesting conditions. I
> appreciate that generally Microsoft Are Not Our Favourite Software
> Company, but giving them as an example doesn't inherently make unique
> IDs bad, and 128-bit ones are not necessary in this case.

Actually ciaranm's example contained 39 hex digits, which leads to
624bit IDs :-).

-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] Re: New category proposal

[Kevin F. Quinn]

On Wed, May 11, 2005 at 07:09:20, Brian Harring wrote:

> One thing that just clicked in the skull on why flat-tree has issues; > currently it's possible to have a package with the same name, yet a
> differing category (app-vim/sudo vs app-admin/sudo).

Aa flat package namespace would necessitate renaming any existing package name clashes.  The essential problem with categories is that you will always have confusion in some cases as to which category a package should be in; it's natural that some packages will make sense in more than one category.  A good example of this problem with categories can be seen in the CDDB/FreeDB track listing database which does a similar category thing with category/album-hash (the problem is pretty acute there, not least because the probability of clashes in the album-hash is high, but also because people disagree whether their favourite album is new-age, folk, etc).

Here's my suggestion, for what it's worth :)

The layout on disk and the semantics of categories do not need to be related.  I like the idea of using the first character of a package name as the sub-directory name.  This can be extended more deeply as and when necessary to avoid over-large directories which cause problems on some filesystems.  e.g. for sudo you get "s/sudo" and vim-sudo "v/vim-sudo".  This is architecture-neutral, rsyncable, scalable, and not too difficult for users to parse manually (see later for searching through categories).  If the algorithm portage would use to locate a package is such that it doesn't mandate the depth (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/" exists) then overlays can have a different depth to the rsync tree; if you only have a few packages in overlay then they need not be in subdirectories at all.

The key here is to separate the category (metadata) and filesystem layout (implementation detail) from the concept of package name.  This opens up all sorts of possibilities, for example different layouts in CVS, on mirrors and on clients (some kind of custom rsync would be necessary) - but that's going perhaps too far...

Categories become metadata, formally (this is the root of the problem - including the category in the package name is a pollution of the package name).  Once they become properly understood and implemented as metadata, a package being a member of more than one category is a natural consequence.

Whether category should be in the ebuild or in metadata.xml is a another issue.  We already have some metadata in the ebuilds (e.g. DESCRIPTION).  However that's really a separate debate; the question of whether all metadata that isn't version-dependent and doesn't impact the emerge process should be moved from ebuilds to metadata.xml...

Portage would essentially ignore categories.  Some support would be necessary to allow the user to query categories (since 'ls /usr/portage/<category>' would no longer work) - but searching for packages is already a function and would just need to be adapted (and perhaps optimised ;) ).  Indeed just listing out portage directories at the moment is often insufficient to find a suitable package, since package names are often amusing but uninformative acronyms.

The real problem with implementing the above is the amount of work it would take to modify portage and the tree, for relatively little gain at the moment.  I'm certainly not volunteering :)

The benefits include
1) no more "moving packages around the tree"
2) categories can be added to a package in the most natural way
3) overlays can be tidier

The downsides include
1) Massive upheaval in the portage tree
2) Massive upheaval in the portage tree
3) Massive upheaval in the portage tree

well, it's a big downside...

Having said that, some things could be done now.  If a flat package namespace is desirable, the existing package name clashes could be resolved by renaming the few packages that clash.  Category could be added as a field in metadata.xml, so that a package could "belong" to multiple categories.  The query/search tools could be enhanced to scan this metadata (perhaps including the current category directory as an implied entry in the metadata.xml).

Kev.



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal

[Brian Harring]

> On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
> Here's my suggestion, for what it's worth :)
> 
> The layout on disk and the semantics of categories do not need to be related. 
Yes and no.  You're assuming that people don't use the layout on disk for digging 
around without calling portage.  Personally, I do.

> I like the idea of using the first character of a package name as the 
> sub-directory name.  This can be extended more deeply as and when necessary to 
> avoid over-large directories which cause problems on some filesystems.  e.g. 
> for sudo you get "s/sudo" and vim-sudo "v/vim-sudo".  This is 
> architecture-neutral, rsyncable, scalable, and not too difficult for users to 
> parse manually (see later for searching through categories).  If the algorithm 
> portage would use to locate a package is such that it doesn't mandate the depth 
> (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/" 
> exists) then overlays can have a different depth to the rsync tree; if you only 
> have a few packages in overlay then they need not be in subdirectories at all.
Re-asserting that the fs layout *does* matter, how is that more intuitive when trying 
to track down the ebuild for dev-util/diffball ?  How many directories deep would I have 
to go before I reached the ebuild?

The changes I posit aren't anymore friendly to devs doing ebuild work, and requires 
a flat namespace- no conflicts, meaning that we have to choose alternate names for conflicts 
(or the category data winds up in the name).  Like I said, I really dislike debian's flat 
namespace, even if we had a category component to it.

> The key here is to separate the category (metadata) and filesystem layout 
> (implementation detail) from the concept of package name.  This opens up all 
> sorts of possibilities, for example different layouts in CVS, on mirrors and on 
> clients (some kind of custom rsync would be necessary) - but that's going 
> perhaps too far...
This also locks out several possibilities, like relying on dir structure to limit the searches.
You force category classification to be metadata, you need an additional db to do searching, 
and basic atom lookup.  That's 19000+ keys in a db.  No db, and you force a tree 
wide search, which _will_ be as fast as emerge -S is.

> Categories become metadata, formally (this is the root of the problem - 
> including the category in the package name is a pollution of the package name). 
>  Once they become properly understood and implemented as metadata, a package 
> being a member of more than one category is a natural consequence.
Currently, the only conflicts that can occur in searches are package specific.  Atoms, 
the basis of our depends system require categories; as such conflicts *cannot* occur.
Multiple categories per package allows for conflicts to occur in our deps.  This is 
nasty, and again, requires pretty much a walk of the whole tree to verify no conflicts 
(mr_bones_, aka michael sterret would probably quietly curl up and die when his repoman runs, 
which are now under an hour, clear 2 hours again) :)

> Portage would essentially ignore categories.  Some support would be necessary 
> to allow the user to query categories (since 'ls /usr/portage/<category>' would 
> no longer work) - but searching for packages is already a function and would 
> just need to be adapted (and perhaps optimised ;) ).  Indeed just listing out 
> portage directories at the moment is often insufficient to find a suitable 
> package, since package names are often amusing but uninformative acronyms.
Portage can't ignore categories, see the bit above about cat/pkg-ver (cpv from this point
on) conflicts.  cpvs can't conflict, pure and simple under the current layout, which is 
enforce by the single category/fs layout.

What are we gaining?  Ability to find a package under two categories?


> The benefits include
> 1) no more "moving packages around the tree"
cpv conflict.  You aren't moving the fs position of it, but it still requires 
walking the tree and updating all atom's that reference the old position.  

> 2) categories can be added to a package in the most natural way
Elaborate.

> 3) overlays can be tidier
Eh?

> well, it's a big downside...
E'yep. :)

> Having said that, some things could be done now.  If a flat package namespace 
> is desirable, the existing package name clashes could be resolved by renaming 
> the few packages that clash.
74 packages, roughly, out of 9429 roughly.

>  Category could be added as a field in 
> metadata.xml, so that a package could "belong" to multiple categories.
>  The query/search tools could be enhanced to scan this metadata (perhaps including 
> the current category directory as an implied entry in the metadata.xml).
If that's the goal of the "belong to N categories" thread, strictly searching, 
sure, although I don't like it.  It can't become an atom for *DEPEND due to the cpv 
nonconflicting bit.
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal

[Georgi Georgiev]

maillog: 11/05/2005-03:40:04(-0500): Brian Harring types
> > On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
> > Here's my suggestion, for what it's worth :)
> > 
> > The layout on disk and the semantics of categories do not need to be related. 
> Yes and no.  You're assuming that people don't use the layout on disk for digging 
> around without calling portage.  Personally, I do.
> 
> > I like the idea of using the first character of a package name as the 
> > sub-directory name.  This can be extended more deeply as and when necessary to 
> > avoid over-large directories which cause problems on some filesystems.  e.g. 
> > for sudo you get "s/sudo" and vim-sudo "v/vim-sudo".  This is 
> > architecture-neutral, rsyncable, scalable, and not too difficult for users to 
> > parse manually (see later for searching through categories).  If the algorithm 
> > portage would use to locate a package is such that it doesn't mandate the depth 
> > (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/" 
> > exists) then overlays can have a different depth to the rsync tree; if you only 
> > have a few packages in overlay then they need not be in subdirectories at all.
> Re-asserting that the fs layout *does* matter, how is that more intuitive when trying 
> to track down the ebuild for dev-util/diffball ?


The fact that the directory where diffball is is easily deducable by its
name. As it is, I'd be a bit lost if I had to guess whether diffball is
in app-arch or dev-util. Even if I remembered it was something
dev-related I'd still be inclined to look in sys-devel.

As it is, for those who don't use a given package on an everyday basis
the categories are extremely obscure.

> How many directories deep would I have to go before I reached the
> ebuild?

Does it matter? You know the path exactly. It's p/portage. It's
not ... "was it sys-apps/portage or app-portage/portage"?

... skip a bit ...

> > Having said that, some things could be done now.  If a flat package namespace 
> > is desirable, the existing package name clashes could be resolved by renaming 
> > the few packages that clash.
> 74 packages, roughly, out of 9429 roughly.

76/9295, which is not that bad, considering about half of them are
emacs/xemacs related.

> >  Category could be added as a field in 
> > metadata.xml, so that a package could "belong" to multiple categories.
> >  The query/search tools could be enhanced to scan this metadata (perhaps including 
> > the current category directory as an implied entry in the metadata.xml).
> If that's the goal of the "belong to N categories" thread, strictly searching, 
> sure, although I don't like it.  It can't become an atom for *DEPEND due to the cpv 
> nonconflicting bit.

I personally want to see the category part *disappear* from the *DEPEND
which is one of the reasons to advocate a flat tree. If the category (or
part of it) goes in the package name, so be it, but at least there will
be no package moves to break older ebuilds or outdated overlays.

-- 
\    Georgi Georgiev   \  Taxes, n.: Of life's two certainties, the    \
/     chutz@gg3.net    /  only one for which you can get an extension. /
\   +81(90)2877-8845   \                                               \
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal

[Brian Harring]

On Wed, May 11, 2005 at 06:01:17PM +0900, Georgi Georgiev wrote:
> maillog: 11/05/2005-03:40:04(-0500): Brian Harring types
> > > On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
> > > Here's my suggestion, for what it's worth :)
> > > 
> > > The layout on disk and the semantics of categories do not need to be related. 
> > Yes and no.  You're assuming that people don't use the layout on disk for digging 
> > around without calling portage.  Personally, I do.
> > 
> > > I like the idea of using the first character of a package name as the 
> > > sub-directory name.  This can be extended more deeply as and when necessary to 
> > > avoid over-large directories which cause problems on some filesystems.  e.g. 
> > > for sudo you get "s/sudo" and vim-sudo "v/vim-sudo".  This is 
> > > architecture-neutral, rsyncable, scalable, and not too difficult for users to 
> > > parse manually (see later for searching through categories).  If the algorithm 
> > > portage would use to locate a package is such that it doesn't mandate the depth 
> > > (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/" 
> > > exists) then overlays can have a different depth to the rsync tree; if you only 
> > > have a few packages in overlay then they need not be in subdirectories at all.
> > Re-asserting that the fs layout *does* matter, how is that more intuitive when trying 
> > to track down the ebuild for dev-util/diffball ?
> 
> 
> The fact that the directory where diffball is is easily deducable by its
> name. As it is, I'd be a bit lost if I had to guess whether diffball is
> in app-arch or dev-util. Even if I remembered it was something
> dev-related I'd still be inclined to look in sys-devel.
dev-util is accurate (it's a compressor, but a specialized variant, 
same as patch is).  From it's current fs location/layout, we get thus- 
quick lookup on the atom, and inference of it's intentions.  This is 
why we have xml at the category level, for example.

One thing that's being unstated also- it's implicitly stated that this 
directory structure is somehow easier to look up a package.  If you 
know the _exact_ package name, maybe.  Otherwise, you're falling back 
to a search tool (which defeats to some degree the whole arguement for 
flattened namespace).
Some quicky python, grouping by first char of the package name, and 
you wind up with (top 8)-
421, 521, 571, 582, 657, 663, 664, 746
Seperate directories within an individual directory.  Say 'd' for 
example, and we'll pretend 746 is the count of packages that start 
with 'd'.  That's a butload of directories to go digging in.

The response would be, "well then extend it to the first two chars 
after the first dir".  You narrow it down, but add another layer of 
dirs, again, for what gain?

See, the thing I find odd about this thread/request is that 
essentially breaking it down to first letter groupping, is being 
argued as being _easier_ for people, while allowing multi cats, or 
just flat out dropping the category aspect.  The example above, imo, 
proves otherwise.

Keep in mind at this point, the discussion is whats easiest for 
_humans_.  What's easiest for code/comp is another matter, and (within 
limits) can work with anything that's thrown at it.

> > How many directories deep would I have to go before I reached the
> > ebuild?
> 
> Does it matter? You know the path exactly. It's p/portage. It's
> not ... "was it sys-apps/portage or app-portage/portage"?
I know the path as sys-apps/portage already though.  Doesn't that 
count for something? :)

Or, a bit more likely case, I know the type of the package, the 
category, but don't recall it's exact name.  What y'all are proposing 
forces the user to use a tool, rather then just a quicky ls.

> > > Having said that, some things could be done now.  If a flat package namespace 
> > > is desirable, the existing package name clashes could be resolved by renaming 
> > > the few packages that clash.
> > 74 packages, roughly, out of 9429 roughly.
> 
> 76/9295, which is not that bad, considering about half of them are
> emacs/xemacs related.
'cept either you, or someone else was proposing a totally flat 
namespace, no cats in the atoms.  That means the count of changes (the 
76 above is just # of conflicting packages) is around 19000, plus a 
fairly large amount of portage modifications.

> > >  Category could be added as a field in 
> > > metadata.xml, so that a package could "belong" to multiple categories.
> > >  The query/search tools could be enhanced to scan this metadata (perhaps including 
> > > the current category directory as an implied entry in the metadata.xml).
> > If that's the goal of the "belong to N categories" thread, strictly searching, 
> > sure, although I don't like it.  It can't become an atom for *DEPEND due to the cpv 
> > nonconflicting bit.
> 
> I personally want to see the category part *disappear* from the *DEPEND
> which is one of the reasons to advocate a flat tree. If the category (or
> part of it) goes in the package name, so be it, but at least there will
> be no package moves to break older ebuilds or outdated overlays.
Frankly, you need to give a *really* damn good reason for why this is 
better.  I don't think it is, convince me otherwise.

What do we gain from a flat namespace?
Right now, I can infer an atom out of a DEPEND string's purpose to 
some degree, based upon it's category.  To head off the "well you 
don't need to know the category, you should know the packages 
intentions if you're modifying the ebuild", that dodges the point; via 
the category portion of an atom, I can infer at least -intention- of a 
package.

Ignoring changes required (have stated them already, no point in 
sniping ya over it), what _exactly_ do we gain from the change?
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Harring wrote:
> On Wed, May 11, 2005 at 06:01:17PM +0900, Georgi Georgiev wrote:
> 
>>maillog: 11/05/2005-03:40:04(-0500): Brian Harring types
>>
>>>>On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
>>>>Here's my suggestion, for what it's worth :)
>>>>
>>>>The layout on disk and the semantics of categories do not need to be related. 
>>>
>>>Yes and no.  You're assuming that people don't use the layout on disk for digging 
>>>around without calling portage.  Personally, I do.
   Not need to be related, but shouldn't be related.  In essence this
allows people to put the tree where-ever, as long as that storage
mechanism supports the database operations required ( stuffing
everything in a SQL db fex ).  I don't know why someone would....but hey ;)
>>>
>>>
>>>>I like the idea of using the first character of a package name as the 
>>>>sub-directory name.  This can be extended more deeply as and when necessary to 
>>>>avoid over-large directories which cause problems on some filesystems.  e.g. 
>>>>for sudo you get "s/sudo" and vim-sudo "v/vim-sudo".  This is 
>>>>architecture-neutral, rsyncable, scalable, and not too difficult for users to 
>>>>parse manually (see later for searching through categories).  If the algorithm 
>>>>portage would use to locate a package is such that it doesn't mandate the depth 
>>>>(i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/" 
>>>>exists) then overlays can have a different depth to the rsync tree; if you only 
>>>>have a few packages in overlay then they need not be in subdirectories at all.
>>>
>>>Re-asserting that the fs layout *does* matter, how is that more intuitive when trying 
>>>to track down the ebuild for dev-util/diffball ?
>>
>>
>>The fact that the directory where diffball is is easily deducable by its
>>name. As it is, I'd be a bit lost if I had to guess whether diffball is
>>in app-arch or dev-util. Even if I remembered it was something
>>dev-related I'd still be inclined to look in sys-devel.
> 
> dev-util is accurate (it's a compressor, but a specialized variant, 
> same as patch is).  From it's current fs location/layout, we get thus- 
> quick lookup on the atom, and inference of it's intentions.  This is 
> why we have xml at the category level, for example.
> 
> One thing that's being unstated also- it's implicitly stated that this 
> directory structure is somehow easier to look up a package.  If you 
> know the _exact_ package name, maybe.  Otherwise, you're falling back 
> to a search tool (which defeats to some degree the whole arguement for 
> flattened namespace).
> Some quicky python, grouping by first char of the package name, and 
> you wind up with (top 8)-
> 421, 521, 571, 582, 657, 663, 664, 746
 Assuming the directories are ordered by letter, ( a,b,c,d ) and
subdirectories if present as well, a bsearch wouldn't be bad.  Both are
ordered sets and you can quickly determine the location of a package in
log(n) time.  I don't see a big deal here.
> Seperate directories within an individual directory.  Say 'd' for 
> example, and we'll pretend 746 is the count of packages that start 
> with 'd'.  That's a butload of directories to go digging in.
> 
> The response would be, "well then extend it to the first two chars 
> after the first dir".  You narrow it down, but add another layer of 
> dirs, again, for what gain?
> 
> See, the thing I find odd about this thread/request is that 
> essentially breaking it down to first letter groupping, is being 
> argued as being _easier_ for people, while allowing multi cats, or 
> just flat out dropping the category aspect.  The example above, imo, 
> proves otherwise.
> 
> Keep in mind at this point, the discussion is whats easiest for 
> _humans_.  What's easiest for code/comp is another matter, and (within 
> limits) can work with anything that's thrown at it.
> 
> 
>>>How many directories deep would I have to go before I reached the
>>>ebuild?
>>
>>Does it matter? You know the path exactly. It's p/portage. It's
>>not ... "was it sys-apps/portage or app-portage/portage"?
> 
> I know the path as sys-apps/portage already though.  Doesn't that 
> count for something? :)
> 
> Or, a bit more likely case, I know the type of the package, the 
> category, but don't recall it's exact name.  What y'all are proposing 
> forces the user to use a tool, rather then just a quicky ls.

  *tongue in cheek* and what is ls but another tool for listing the
contents of a directory :)

>>>>Having said that, some things could be done now.  If a flat package namespace 
>>>>is desirable, the existing package name clashes could be resolved by renaming 
>>>>the few packages that clash.
>>>
>>>74 packages, roughly, out of 9429 roughly.
>>
>>76/9295, which is not that bad, considering about half of them are
>>emacs/xemacs related.
> 
> 'cept either you, or someone else was proposing a totally flat 
> namespace, no cats in the atoms.  That means the count of changes (the 
> 76 above is just # of conflicting packages) is around 19000, plus a 
> fairly large amount of portage modifications.
> 
> 
>>>> Category could be added as a field in 
>>>>metadata.xml, so that a package could "belong" to multiple categories.
>>>> The query/search tools could be enhanced to scan this metadata (perhaps including 
>>>>the current category directory as an implied entry in the metadata.xml).
>>>
>>>If that's the goal of the "belong to N categories" thread, strictly searching, 
>>>sure, although I don't like it.  It can't become an atom for *DEPEND due to the cpv 
>>>nonconflicting bit.
>>
>>I personally want to see the category part *disappear* from the *DEPEND
>>which is one of the reasons to advocate a flat tree. If the category (or
>>part of it) goes in the package name, so be it, but at least there will
>>be no package moves to break older ebuilds or outdated overlays.
> 
> Frankly, you need to give a *really* damn good reason for why this is 
> better.  I don't think it is, convince me otherwise.
> 
> What do we gain from a flat namespace?
> Right now, I can infer an atom out of a DEPEND string's purpose to 
> some degree, based upon it's category.  To head off the "well you 
> don't need to know the category, you should know the packages 
> intentions if you're modifying the ebuild", that dodges the point; via 
> the category portion of an atom, I can infer at least -intention- of a 
> package.

The CPV thing.....is a big fix :(

> Ignoring changes required (have stated them already, no point in 
> sniping ya over it), what _exactly_ do we gain from the change?
> ~brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQoIghmzglR5RwbyYAQJa4w//WOTxQGm59JK96uX2MlLTlIG9kjFRhKTk
AJjPybvOrJEngUuqhCogzxtsz0FXOX096bUyBO0CZb0mfN7hwW4jZIMDHycYD/kI
AW22E/SrlH4iHi/UrQNzOm2kT6hgg1Vnnt/PqU/W1CqWF3xs8hFOYui61FW9U1WO
Wq5vfxPZQd3cjRT1JQbIX3KJtmzYq8tnfWEaUo9kkSMlIWViFlvH0chEi7s61Na/
W/jfmscHBfx2y2pkITaRHO+JO3DgG412YKmfRe0JuOmcjGLwnrChQZqgSpTaE8e6
6d+ocqtTdAnJc52CbGCNN5RLnkmmYsOFGBtDEc4JKmYoRZZeWszI9QE6Dt+0i+mm
rZAMtVvdRHE3A72cKF+4UiqvhIO2hAdzRE4i4m0h5WAsKrMDXIobeGunROHGCCyu
ctsgH24OcTxX1D0syiQcvB+lvSyxDb2JBnd4gMSDpwEEQrZ9YxLkEVN830XZ6kaV
FLxUj4zyl67iejabfNNBmTymV1i84z3BMeXKayrVp77NUF0swCOC6rlciCFfoSLQ
N5vyFjwEcMsUWnSO2cq5laNDRqIjlw/YfO0Hiy55TCFi/vm5sH44rehntMyq1b3h
xcLJhq7MIPmkfO2qZSZfD8ouB621bAlh4Vc+x+7kyLFaFRdAIQHYIY3rB3DFR5k9
ETcl3w/XVq8=
=SN4n
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal

[Brian Harring]

On Wed, May 11, 2005 at 11:11:02AM -0400, Alec Warner wrote:
> >>>Yes and no.  You're assuming that people don't use the layout on disk for digging 
> >>>around without calling portage.  Personally, I do.
>    Not need to be related, but shouldn't be related.  In essence this
> allows people to put the tree where-ever, as long as that storage
> mechanism supports the database operations required ( stuffing
> everything in a SQL db fex ).  I don't know why someone would....but hey ;)

Not a valid arguement for dropping categories however, since I'm 
playing with sqlite based repository module atm locally :)
(don't ask for it, it's not even remotely ready for any use beyond
destroying things locally on my box at the moment)

Category is just a bit of info used for looking up a node (category="xyz" 
and package="abc").  Shouldn't isn't applicable here; in this case, 
category *is* required due to our atoms, unless people manage to push 
flattening the namespace through. :)


> >>The fact that the directory where diffball is is easily deducable by its
> >>name. As it is, I'd be a bit lost if I had to guess whether diffball is
> >>in app-arch or dev-util. Even if I remembered it was something
> >>dev-related I'd still be inclined to look in sys-devel.
> > 
> > dev-util is accurate (it's a compressor, but a specialized variant, 
> > same as patch is).  From it's current fs location/layout, we get thus- 
> > quick lookup on the atom, and inference of it's intentions.  This is 
> > why we have xml at the category level, for example.
> > 
> > One thing that's being unstated also- it's implicitly stated that this 
> > directory structure is somehow easier to look up a package.  If you 
> > know the _exact_ package name, maybe.  Otherwise, you're falling back 
> > to a search tool (which defeats to some degree the whole arguement for 
> > flattened namespace).
> > Some quicky python, grouping by first char of the package name, and 
> > you wind up with (top 8)-
> > 421, 521, 571, 582, 657, 663, 664, 746
>  Assuming the directories are ordered by letter, ( a,b,c,d ) and
> subdirectories if present as well, a bsearch wouldn't be bad.  Both are
> ordered sets and you can quickly determine the location of a package in
> log(n) time.  I don't see a big deal here.

Dodging my point though.  I was pointing out that the categories 
approach decreases the number of directories/packages within each 
grouping, while first letter approach jacks up the # of dirs w/in dirs 
(in some cases, of course).  basically, a category fs layout is easier 
on the human who is digging in if they don't know what they're exactly 
hunting for, point still stands. :)

Regarding bsearch, ehh.  listdir returns a list (not an iterable over 
the (open|read|close)dir syscall), so you'd have to either resort to a 
linear search, or sort then bsearch it.  Like I said, the issue isn't 
how we code things to make it speedy, my concern outlined above is 
purely the human factor in dealing with the proposed tree 
structure.


> > I know the path as sys-apps/portage already though.  Doesn't that 
> > count for something? :)
> > 
> > Or, a bit more likely case, I know the type of the package, the 
> > category, but don't recall it's exact name.  What y'all are proposing 
> > forces the user to use a tool, rather then just a quicky ls.
> 
>   *tongue in cheek* and what is ls but another tool for listing the
> contents of a directory :)

ls does no good if you're trying to see all packages of a category, 
under this proposal, which is what I'm driving at.  It forces the user 
to use scripts/tools to do querying.

> >>I personally want to see the category part *disappear* from the *DEPEND
> >>which is one of the reasons to advocate a flat tree. If the category (or
> >>part of it) goes in the package name, so be it, but at least there will
> >>be no package moves to break older ebuilds or outdated overlays.
> > 
> > Frankly, you need to give a *really* damn good reason for why this is 
> > better.  I don't think it is, convince me otherwise.
> > 
> > What do we gain from a flat namespace?
> > Right now, I can infer an atom out of a DEPEND string's purpose to 
> > some degree, based upon it's category.  To head off the "well you 
> > don't need to know the category, you should know the packages 
> > intentions if you're modifying the ebuild", that dodges the point; via 
> > the category portion of an atom, I can infer at least -intention- of a 
> > package.
> 
> The CPV thing.....is a big fix :(
> 
> > Ignoring changes required (have stated them already, no point in 
> > sniping ya over it), what _exactly_ do we gain from the change?

So... what do we gain?  Like I said, ignore for a second that massive 
overhaul required; if work is required to gain something, and what's 
gained is worth it over the work, sure.  I'm not seeing the gain 
though :)

The original request was having a package turn up in multiple 
categories for searching, right?  I don't like it, but metadata.xml at 
the package level could probably be extended for that, *strictly* for 
searching.  It cannot, *ever* be used for satisfying an atom imo.  
Reason being it allows for the cpv conflict, rather then just package 
conflicts we have now.
~Brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal

[Georgi Georgiev]

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

maillog: 11/05/2005-10:33:23(-0500): Brian Harring types
> The original request was having a package turn up in multiple 
> categories for searching, right?

Actually, that was a side effect. The original request was to stop
moving packages around, which is the most annoying part and is also the
part that consumes a lot of effort. After all, this started as a result
of a discussion about the new name of a category. There were also talks
about whether some package should be in here or there... Having a flat
tree is one way to solve the discussed problem and which would also
allow me to find some package quickly. The flat tree request I, at
least personally, am willing to drop if you offer an alternative
solution to the keep-them-package-atoms-fixed-once-and-for-all problem.
Ahem, by an "atom" in this sentence I was referring to the CP part of
CPV.

-- 
\/   Georgi Georgiev   \/ When all other means of communication        \/
/\    chutz@gg3.net    /\ fail, try words.                             /\
\/  +81(90)2877-8845   \/                                              \/

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

Re: [gentoo-dev] Re: New category proposal

[Kevin F. Quinn]

Brian Harring wrote:
> > The layout on disk and the semantics of categories do not need to be > > related.
> Yes and no.  You're assuming that people don't use the layout on 
> disk for digging around without calling portage.  Personally, I do.

Sometimes I do the same; but other times I find the layout a barrier.  Many's the time I've done:

$ ls -d /usr/portage/*/<package name pattern>

to find a package, for example - that indicates the categories are actually hindering searches in this case.  Incidentally it also treats the tree as if it were a flat namespace.

However, ideally I wouldn't be searching the tree directly like that at all, I'd be searching metadata based on various criteria.  Indeed package names as they stand are frequently uninformative; if you decide you need something for a particular function, you can have a look in what you think may be the relevant categories, only to find a list of mostly meaningless package names.  Then you start grepping the DESCRIPTIONs, and so on finally trying equery.  This whole process is rather unsatisfactory, and in my experience often fruitless.  Many times I've gone the other way; google for something to find candidate package names, then 'ls -d /usr/portage/*/<name>' to see if some kind soul has already added an ebuild to the tree.

For me, the whole point of a flat namespace is to _remove_ categories from the atom.  Obviously this has far-reaching disruptive consequences as you describe, and in practice is not workable in the short to medium term at least.

I'd like to be able to ask questions like, "what app-text packages exist for <some function>?".  At the moment, listing app-text, grepping app-text/*/*ebuild may get somewhere, but what about packages placed in different categories for reasons like name clash, other functionality and so on?

Cieran McCreesh wrote:
> So we end up not using upstream naming, leading to major hassle with
> tarballs, major user confusion and inconsistent naming (why are some vim
> things vim- and others not?). Bad! Now that portage *tells* you when you
> need to be more specific, there's no problem with name matches.

I agree maintaing upstream naming is very important.  However obviously upstream names can and do clash.  That raises the question of how such clashes should be resolved.  Categories are a rather arbitrary way of doing that - it's quite possible that a clash could occur between two packages that naturally fall into the same category - in the current system that means one of the packages gets dumped in a second-choice category.

Talking atoms, one could handle clashes by differentiating occurrences with an extension to the name.  To take the sudo example, sudo could be the normal sudo, sudo:vim (or perhaps sudo__vim to be acceptable to more filesystems) could be the vim extension sudo.

Brian Harring wrote:
> Re-asserting that the fs layout *does* matter, how is that more intuitive > when trying 
> to track down the ebuild for dev-util/diffball ?  How many directories > deep would I have to go before I reached the ebuild?

$ ls -d /usr/portage/*/<name pattern>

becomes

$ find /usr/portage -type d -name <name pattern> -print

and for quick&dirty things like

$ grep -l <pattern> /usr/portage/*/<name pattern>/*ebuild

instead do:

$ find /usr/portage -type d -name <name pattern> \
    -exec grep -l <pattern> \{\}/*ebuild \;

or somesuch.


An interesting possibility is that the portage mirrors and clients can have different layouts depending what is most suitable.  Those with reiserfs could sensibly choose the very wide layout.  Others on ext2 could choose a s/u/sudo approach to avoid problems with very wide directories.  Obviously this means modifying the sync process somewhat deal with this, but it's quite possible, in a scalable efficient manner.

Brian Harring wrote:
> > The key here is to separate the category (metadata) and filesystem  [snip]
> This also locks out several possibilities, like relying on dir structure > to limit the searches.
> You force category classification to be metadata, you need an additional > db to do searching, 
> and basic atom lookup.  That's 19000+ keys in a db.  No db, and you force > a tree wide search, which _will_ be as fast as emerge -S is.

If you retain category in the atom; for me there's no point flattening the namespace without removing the category completely from the atom.

Where at the moment you perhaps want to do:

$ grep <pattern> /usr/portage/app-text/*/*ebuild

then yes, an additional db of some kind is necessary, or perhaps a more efficient way of searching the metadata.xml files.  However I disagree with the 19000+ keys.  Portage could for example maintain a simple category->package name mapping - only needs to be updated when packages are added/removed from the tree or metadata is changed, and can be trivial.  For example, it could be a simple shell script with entries like:

PC_<category>=<name> <name> <name>

at which point you only need to do:

$ source <category db>
$ for pkg in ${PC_<category>}; do ... ; done

Brian Harring wrote:
> cpvs can't conflict, pure and simple under the current 
> layout, which is 
> enforce by the single category/fs layout.

cpvs can't conflict because when a package name already exists in a category, a conflicting package name has to go into a different category even if it's not the most natural category for the package.  What you've done there, is assert a rule (cpvs are unique) thus 

Brian Harring wrote:
> What are we gaining?  Ability to find a package under two categories?

That, and stability of package location.  Moving packages around the tree is disruptive, not just to ebuilds that reference them but also cause unnecessary mirror activity.

For me, categories are a search criteria.  Making them part of the tree makes it difficult to revise those criteria.

Brian Harring wrote:
> > The benefits include
> > 1) no more "moving packages around the tree"
> cpv conflict.  You aren't moving the fs position of it, but it still 
> requires walking the tree and updating all atom's that reference the old > position.
The point is that *DEPEND would not mention the category.

Brian Harring wrote:
> > 2) categories can be added to a package in the most natural way
> Elaborate.

The idea is that packages can naturally belong in more than one category.  Thinking of categories more like search keywords, if you like.  A package that processes text would match app-text, but perhaps it's also a financial tool which would therefore also match app-finance.

Another good example of the usefulness of more than one category are the sys-* categories, where all the packages in sys-* categories naturally fall both into their sys- category but also the relevant non-sys category.  Take GCC; currently in sys-devel/gcc, not in dev-lang/gcc which is where a naive user would look for it.  With multiple category markings, it could be in both.

Brian Harring wrote:
> > 3) overlays can be tidier
> Eh?

This is a result of the dynamic s/u/sudo approach where the directory depth is arbitrary.  In the overlay you could drop the s/u/ bit.  I'd guess most overlays modify relatively few packages; I know I have a bunch of categories in my overlay that only contain one package.  Given that portage would take a top-down search approach to locate the package (i.e. try sudo, then s/sudo, then s/u/sudo ... first in overlay then in the mirror) this works transparently.

Brian Harring wrote:
> What do we gain from a flat namespace?

Eliminating categories from package names

> Right now, I can infer an atom out of a DEPEND string's purpose to 
> some degree, based upon it's category.

You could use this argument for appending the description to the atom, but noone would suggest such a thing seriously.  What you're justifying, is building metadata into the package name.

> To head off the "well you 
> don't need to know the category, you should know the packages 
> intentions if you're modifying the ebuild", that dodges the point; via > the category portion of an atom, I can infer at least -intention- of a > package.

To be more accurate, you can infer an aspect of the intention of a package that the original committer felt was most important whilst avoiding clashes. That's the point - by forcing a package to be a member of exactly one category, the implications from category membership are limited.


I'm the first to admit that doing the changes to the fs layout I've talked about are hugely disruptive, and as such are not sensible, most especially in the short to medium term.  This discussion however does serve to understand the problem properly before making any changes.  I think adding categories to metadata.xml, removing the few clashes (but otherwise leaving the fs layout as it is), and coming up with an efficient search tool (e.g. getting portage to maintain something like the script I mentioned above, or creating a widget to build it from the metadata.xml files) could eliminate the primary problem of moving packages around, and the arguments like should a package be in dev-cpp or dev-libs.  The rule could then be that once a package is in a physical category in the tree then it will not physically move, no matter what.  *DEPEND would continue to use the physical category, at least in the short term - it could ultimately drop the category if that becomes sensible.  Changing the few existing clashing names could be undertaken gradually (e.g. appending :<differentiator> as describe above), to allow clashing names to belong to the same category.


This is quite benign and relatively painless.  Ultimately you have a flat namespace, packages will no longer move inside the fs tree, the old q&d ls/grep tricks to try to find suitable packages would work as well as they do now, arguments about which category to place a package disappear, searches using category can become more intuitive, different packages that have the same upstream name can be members of the same category.

Kev.



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New category proposal

[Martin Schlemmer]

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

On Mon, 2005-05-09 at 13:07 -0400, Aron Griffis wrote:
> Georgi Georgiev wrote:	[Sun May 08 2005, 08:19:20PM EDT]
> > Would it be inappropriate to start bitching (again) about a flat
> > tree where each package can go in multiple categories?
> 
> That's something I'd love to see eventually...  I mean the flat tree,
> not the complaining ;-)
> 

Problem with flat tree, is the search times might then suck even more,
as last I heard, too many dirs/files in one directory have a huge speed
penalty.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


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

[gentoo-dev] multiple categories for a package (was: [gentoo-dev] Re: New category proposal)

[David Klaftenegger]

Georgi Georgiev wrote:
> Would it be inappropriate to start bitching (again) about a flat tree
> where each package can go in multiple categories?

So now, that I've read  all messages in this thread, I needed a point to
start at..
I guess my approach isn't a way to go, but I can't find the reason for
it being bad, so:
Why not just create a symlink to the package in the category it *also*
should be in?

For example, net-mail/mutt could be a symlink to ../mail-client/mutt,
allowing to find it in both categories.

Ok, portage would have to do extra work, as it would have to check
wether a package is a symlink or not, ignore "symlink-packages" when it
comes to ambiguous naming, count them as already installed if the
package it points to is already installed and so on...
quite some work, but from my point of view less than some other solutions.

So I hope you understand what I mean, you may now hang me for this
proposal, but if you do please tell me why it is not a good way to allow
multiple categories per package ;-)

Greetings,
David
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] multiple categories for a package (was: [gentoo-dev] Re: New category proposal)

[Brian Harring]

On Mon, May 16, 2005 at 10:28:48PM +0200, David Klaftenegger wrote:
> Georgi Georgiev wrote:
> > Would it be inappropriate to start bitching (again) about a flat tree
> > where each package can go in multiple categories?
> 
> So now, that I've read  all messages in this thread, I needed a point to
> start at..
> I guess my approach isn't a way to go, but I can't find the reason for
> it being bad, so:
> Why not just create a symlink to the package in the category it *also*
> should be in?
> 
> For example, net-mail/mutt could be a symlink to ../mail-client/mutt,
> allowing to find it in both categories.
> 
> Ok, portage would have to do extra work, as it would have to check
> wether a package is a symlink or not, ignore "symlink-packages" when it
> comes to ambiguous naming, count them as already installed if the
> package it points to is already installed and so on...
> quite some work, but from my point of view less than some other solutions.
> 
> So I hope you understand what I mean, you may now hang me for this
> proposal, but if you do please tell me why it is not a good way to allow
> multiple categories per package ;-)
It's a better approach then tagging it into the metadata imo, since it 
forces unique cat/package still.  Won't play nice if the tree's fs 
doesn't like symlinks though (fat)...

Also doesn't seem incredibly useful to me, although keep in mind I'm 
the lazy bugger who thinks what's there currently suffices :)
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] multiple categories for a package

[David Klaftenegger]

Brian Harring wrote:
> On Mon, May 16, 2005 at 10:28:48PM +0200, David Klaftenegger wrote:
>>Why not just create a symlink to the package in the category it *also*
>>should be in?
>>
>>For example, net-mail/mutt could be a symlink to ../mail-client/mutt,
>>allowing to find it in both categories.
>>
> It's a better approach then tagging it into the metadata imo, since it 
> forces unique cat/package still.  Won't play nice if the tree's fs 
> doesn't like symlinks though (fat)...

Well, instead of a symlink it could also be a textfile containing the
package it points to... but who wants to use a floppy fs for the tree
anyways?

> Also doesn't seem incredibly useful to me, although keep in mind I'm 
> the lazy bugger who thinks what's there currently suffices :)
> ~brian

The discussion lasted long enough for me to think about the problem;
I personally would save 10 seconds to a minute every now and then if
there were multiple categories, so I'd like it, but I don't know if that
little gain would justify the effort to implement it.

Greetings,
David
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] multiple categories for a package

[Jan Kundrát]

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

David Klaftenegger wrote:
>>>Why not just create a symlink to the package in the category it *also*
>>>should be in?
[snip]
>>It's a better approach then tagging it into the metadata imo, since it 
>>forces unique cat/package still.  Won't play nice if the tree's fs 
>>doesn't like symlinks though (fat)...
[snip]
> Well, instead of a symlink it could also be a textfile containing the
> package it points to... but who wants to use a floppy fs for the tree
> anyways?

As someone stated on #gentoo-dev, is CVS/rsync happy with symlinks? Or
would it need another functionality to Portage to create those links in
the "updating cache" phase after sync?

-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] multiple categories for a package

[Marius Mauch]

David Klaftenegger wrote:
> Georgi Georgiev wrote:
> 
>>Would it be inappropriate to start bitching (again) about a flat tree
>>where each package can go in multiple categories?
> 
> 
> So now, that I've read  all messages in this thread, I needed a point to
> start at..
> I guess my approach isn't a way to go, but I can't find the reason for
> it being bad, so:
> Why not just create a symlink to the package in the category it *also*
> should be in?
> 
> For example, net-mail/mutt could be a symlink to ../mail-client/mutt,
> allowing to find it in both categories.
> 
> Ok, portage would have to do extra work, as it would have to check
> wether a package is a symlink or not, ignore "symlink-packages" when it
> comes to ambiguous naming, count them as already installed if the
> package it points to is already installed and so on...
> quite some work, but from my point of view less than some other solutions.
> 
> So I hope you understand what I mean, you may now hang me for this
> proposal, but if you do please tell me why it is not a good way to allow
> multiple categories per package ;-)

CVS doesn't support symlinks.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] multiple categories for a package

[Alin Nastac]

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

Marius Mauch wrote:

>
> CVS doesn't support symlinks.
>
But subversion does ;)

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

Re: [gentoo-dev] multiple categories for a package

[Marius Mauch]

Alin Nastac wrote:
> Marius Mauch wrote:
> 
> 
>>CVS doesn't support symlinks.
>>
> 
> But subversion does ;)

Doesn't help here.
-- 
gentoo-dev@gentoo.org mailing list