Mailing List Archive

* 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

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.

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

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

* 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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

> 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