Re: [gentoo-dev] Re: Re: New category proposal
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
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: New category proposal
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
[gentoo-dev] Re: Re: New category proposal
Brian Harring posted [EMAIL PROTECTED], 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
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
Re: [gentoo-dev] Re: Re: New category proposal
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? / \ [EMAIL PROTECTED]\ \ / +81(90)2877-8845/ / -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: New category proposal
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 / \ [EMAIL PROTECTED]\ just look at the source code. -- Dave Olson \ / +81(90)2877-8845/ / -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: New category proposal
maillog: 11/05/2005-16:41:37(+0100): Ciaran McCreesh types On Tue, 10 May 2005 22:59:42 -0700 Duncan [EMAIL PROTECTED] 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 [EMAIL PROTECTED] else. +81(90)2877-8845 pgpLEfFlMmYqI.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: New category proposal
On Thu, 12 May 2005 02:21:28 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | maillog: 11/05/2005-16:41:37(+0100): Ciaran McCreesh types | On Tue, 10 May 2005 22:59:42 -0700 Duncan [EMAIL PROTECTED] | 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 pgp7xaROcuPxY.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: New category proposal
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 fixpackaged - 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 \/ /\[EMAIL PROTECTED]/\ answers, only cross references. /\ \/ +81(90)2877-8845 \/ \/ pgpV1tpgHnZ1Z.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: New category proposal
On Thu, 12 May 2005 04:01:17 +0900 Georgi Georgiev [EMAIL PROTECTED]
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
pgphXSss62FjU.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Re: New category proposal
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: Martin Schlemmer posted [EMAIL PROTECTED], 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
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
