[gentoo-dev] New app-eselect category?

[gentoo-dev] New app-eselect category?

[Ulrich Mueller]

As of today, app-admin contains 179 packages.
We could move the 27 eselect-* packages to a new app-eselect category
(eselect itself would stay in app-admin).

Opinions?

Ulrich

Re: [gentoo-dev] New app-eselect category?

[Tiziano Müller]

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

Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller:
> As of today, app-admin contains 179 packages.
> We could move the 27 eselect-* packages to a new app-eselect category
> (eselect itself would stay in app-admin).
> 
> Opinions?

Yes in general. Maybe think about what happens when the Universal Select
Tool gets released/used. Possible alternative: app-select?

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] New app-eselect category?

[Philipp Riegger]

Hello world!

On Tue, 2009-05-26 at 16:24 +0200, Tiziano Müller wrote:
> Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller:
> > As of today, app-admin contains 179 packages.
> > We could move the 27 eselect-* packages to a new app-eselect category
> > (eselect itself would stay in app-admin).
> > 
> > Opinions?
> 
> Yes in general. Maybe think about what happens when the Universal Select
> Tool gets released/used. Possible alternative: app-select?

How will that tool be called? Maybe uselect?

Another alternative: app-xselect.

Philipp

Re: [gentoo-dev] New app-eselect category?

[Federico Ferri]

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

Philipp Riegger wrote:
> Hello world!
>
> On Tue, 2009-05-26 at 16:24 +0200, Tiziano Müller wrote:
>> Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller:
>>> As of today, app-admin contains 179 packages. We could move the
>>> 27 eselect-* packages to a new app-eselect category (eselect
>>> itself would stay in app-admin).
>>>
>>> Opinions?
>> Yes in general. Maybe think about what happens when the Universal
>> Select Tool gets released/used. Possible alternative: app-select?
>>
>
> How will that tool be called? Maybe uselect?
>
> Another alternative: app-xselect.
>

seems like here two-level categories are a limitation.

if three-level categories were available, I'd say app-admin-xselect.

since the last two levels make more sense, compared to the 1+3, if you
believe the app-admin category is too crowded, why not just make a new
category admin-XYZ, thus adding the missing third level?

- --
Federico Ferri (mescalinum)
> Philipp
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkocAeQACgkQV/B5axfzrPv12gCeO8tVVCvJcqb0OK4qsFBxELe3
VuoAoKub0H7s1u0yvPR9n4DSNeKmN+rE
=dovF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New app-eselect category?

[George Shapovalov]

Tuesday, 26. May 2009, Federico Ferri Ви написали:
> seems like here two-level categories are a limitation.
>
> if three-level categories were available, I'd say app-admin-xselect.
Argh, should we suffer the same issues over again? What about just dropping 
the two/three/etc tier requirement and just go for arbitrary nestedness? So, 
your example would become
app/admin/xselect
(plus we would have a tidier top-level of portage)
Its not like tree walker is prohibitively sophisticated piece of code..

NOTE: I am not proposing to do this now (considering how things go, such a 
move is unrealistic to expect in any foreseeable future :)). However if we do 
(eventually; right, if this is ever gonna happen), lets do it right, so that 
we do not have to readdress the same issue over and over again..

George

Re: [gentoo-dev] New app-eselect category?

[Sérgio Almeida]

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

Hello,

I am the student doing the Universal Select Tool for this year's
Geetoo's SoC.

On Tue, 2009-05-26 at 16:35 +0200, Philipp Riegger wrote:

> 
> How will that tool be called? Maybe uselect?

Everything points out to that until now. =)

The way it's done, current eselect modules can continue working with
uselect with very few changes needed. I didn't want to add full
backwards compatibility because the utilities are slightly different and
therefore creating the sense that uselect is not yet another eselect. At
this time (SoC starts in a few hours) the prototype is written in
python, does everything eselect does and supports any scripting language
for module's actions. Oh, it's extremely faster too. Drop me a line at
"[gentoo-dev] Google SoC @ Gentoo - Universal Select Tool" thread if you
have any ideas. Thank you!

Cheers,
Sérgio



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

Re: [gentoo-dev] New app-eselect category?

[Nirbheek Chauhan]

2009/5/27 Sérgio Almeida <mephx.x@gmail.com>:
> this time (SoC starts in a few hours) the prototype is written in
> python, does everything eselect does and supports any scripting language
> for module's actions. Oh, it's extremely faster too.

You have a working prototype right now? Awesome! Where's the ebuild for it?



-- 
~Nirbheek Chauhan

Re: [gentoo-dev] New app-eselect category?

[Sérgio Almeida]

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

On Wed, 2009-05-27 at 01:19 +0530, Nirbheek Chauhan wrote:
> 2009/5/27 Sérgio Almeida <mephx.x@gmail.com>:
> > this time (SoC starts in a few hours) the prototype is written in
> > python, does everything eselect does and supports any scripting language
> > for module's actions. Oh, it's extremely faster too.
> 
> You have a working prototype right now? Awesome! Where's the ebuild for it?
> 

Hello,

There isn't yet. The code is still pretty ugly and I'm still refactoring
to the new architecture before I can make it public (or even officially
git it). I will post it on this mailing list as soon as experimentations
are possible.

As a teaser...

sym /usr/src/linux /usr/src/ linux-(.*)

This is all that the kernel module needs so that it can list available
options, select a new option, view the current option. The new uselect
Kernel module has 10 lines instead of eselect's 100.

Cheers,
Sérgio

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

Re: [gentoo-dev] New app-eselect category?

[Rémi Cardona]

Le 26/05/2009 22:43, Sérgio Almeida a écrit :
> Hello,
>
> There isn't yet. The code is still pretty ugly and I'm still refactoring
> to the new architecture before I can make it public (or even officially
> git it). I will post it on this mailing list as soon as experimentations
> are possible.

Please do try to make it available somewhere (even if only with a dumb 
live -9999 git ebuild) so that we can actually try it out.

I can't remember when was the last Gentoo GSoC project that we were 
actually able to use/see/build...

Good luck for your Summer of Code :)

Rémi

Re: [gentoo-dev] New app-eselect category?

[Fabian Groffen]

On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote:
> As of today, app-admin contains 179 packages.
> We could move the 27 eselect-* packages to a new app-eselect category
> (eselect itself would stay in app-admin).
> 
> Opinions?

I hate package moves, so is it really *really* necessary?


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] New app-eselect category?

[AllenJB]

Fabian Groffen wrote:
> On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote:
>> As of today, app-admin contains 179 packages.
>> We could move the 27 eselect-* packages to a new app-eselect category
>> (eselect itself would stay in app-admin).
>>
>> Opinions?
> 
> I hate package moves, so is it really *really* necessary?
> 
> 
I have to agree. app-admin is hardly among the largest categories. 
Perhaps we should consider splitting up the 400 odd packages in kde-base 
(kde-graphics, kde-admin, kde-games, etc)  =P

As for app-admin-eselect, I'd favor tags over increasing the category 
levels, tho I'm not convinced either is necessary at the current time 
(tho tags might make searching easier, in some ways).

AllenJB

Re: [gentoo-dev] New app-eselect category?

[Theo Chatzimichos]

On Tuesday 26 May 2009 18:31:17 AllenJB wrote:
> Fabian Groffen wrote:
> > On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote:
> >> As of today, app-admin contains 179 packages.
> >> We could move the 27 eselect-* packages to a new app-eselect category
> >> (eselect itself would stay in app-admin).
> >>
> >> Opinions?
> >
> > I hate package moves, so is it really *really* necessary?
>
> I have to agree. app-admin is hardly among the largest categories.
> Perhaps we should consider splitting up the 400 odd packages in kde-base
> (kde-graphics, kde-admin, kde-games, etc)  =P
>
> As for app-admin-eselect, I'd favor tags over increasing the category
> levels, tho I'm not convinced either is necessary at the current time
> (tho tags might make searching easier, in some ways).
>
> AllenJB

kde-base is OK please don't touch :) Also i removed one package from kde-base 
today :P
-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE Team

Re: [gentoo-dev] New app-eselect category?

[Federico Ferri]

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

AllenJB wrote:
> Fabian Groffen wrote:
>> On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote:
>>> As of today, app-admin contains 179 packages. We could move the
>>> 27 eselect-* packages to a new app-eselect category (eselect
>>> itself would stay in app-admin).
>>>
>>> Opinions?
>>
>> I hate package moves, so is it really *really* necessary?
>>
>>
> I have to agree. app-admin is hardly among the largest categories.
> Perhaps we should consider splitting up the 400 odd packages in
> kde-base (kde-graphics, kde-admin, kde-games, etc)  =P
>
> As for app-admin-eselect, I'd favor tags over increasing the
> category levels, tho I'm not

the three-levels-category was an example.
the realistic approach I proposed is splitting app-admin in many
two-level categories:
+ admin-eselect
+ admin-sysconf
+ admin-www
+ admin-apache
...
as it usually has been done in such cases.


- --
Federico Ferri (mescalinum)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkocHNoACgkQV/B5axfzrPsCzgCeJZknEWRV1o2SjPpPc9HJ0k1u
bUoAnRygFK/mRPfAguutyUmZWssnPyXh
=hZFu
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New app-eselect category?

[Josh Saddler]

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

AllenJB wrote:
> I'd favor tags over increasing the category
> levels, tho I'm not convinced either is necessary at the current time
> (tho tags might make searching easier, in some ways).

Heck yes! Tags are a good idea. The idea's been raised on -dev a few
times. I suppose they're not (yet) essential, but from a user point of
view, if the tools supported searching for tags buried in metadata.xml,
it would make life much, much nicer.

And if wishes were horses . . . maybe one day we'd all ride. Or at least
argue about what shade of pink to paint the ponies. :p


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

Re: [gentoo-dev] New app-eselect category?

[Tiziano Müller]

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

Am Dienstag, den 26.05.2009, 17:00 -0700 schrieb Josh Saddler:
> AllenJB wrote:
> > I'd favor tags over increasing the category
> > levels, tho I'm not convinced either is necessary at the current time
> > (tho tags might make searching easier, in some ways).
> 
> Heck yes! Tags are a good idea. The idea's been raised on -dev a few
> times. I suppose they're not (yet) essential, but from a user point of
> view, if the tools supported searching for tags buried in metadata.xml,
> it would make life much, much nicer.

And with the risk to repeat myself: herds can already been seen as tags.
So, my proposal still stands: change the current herds into teams and
write them in metadata.xml as such:

<maintainer>
  <team>cpp</team>
</maintainer>

and then using <herd> as tags.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] New app-eselect category?

[Jorge Manuel B. S. Vicetto]

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

Tiziano Müller wrote:
> Am Dienstag, den 26.05.2009, 17:00 -0700 schrieb Josh Saddler:
>> AllenJB wrote:
>>> I'd favor tags over increasing the category
>>> levels, tho I'm not convinced either is necessary at the current time
>>> (tho tags might make searching easier, in some ways).
>> Heck yes! Tags are a good idea. The idea's been raised on -dev a few
>> times. I suppose they're not (yet) essential, but from a user point of
>> view, if the tools supported searching for tags buried in metadata.xml,
>> it would make life much, much nicer.
> 
> And with the risk to repeat myself: herds can already been seen as tags.
> So, my proposal still stands: change the current herds into teams and
> write them in metadata.xml as such:
> 
> <maintainer>
>   <team>cpp</team>
> </maintainer>
> 
> and then using <herd> as tags.

The largest issue I see with the idea of embedding tags in the tree is
that many users think that tags are great, but for them to be *really*
great, the tagging should be done outside of the tree to also allow them
to do the tagging.
Tags in the tree would be another framework at the hands of the devs and
would suffer from the same limitations as the tree - limited dev pool,
shortness of time, too many packages, etc. So at least some users would
like to have that framework open to them so they could contribute and
they hope provide a larger pool of people, with quite a bit of time in
their hands and more than willing to give back.
I like the idea of letting users join the tagging and think it's a way
of fostering the community belonging of Gentoo - besides I don't think
we need to "secure" the tags. I don't have any input on how to implement
that idea, though.


- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkohQaIACgkQcAWygvVEyAIhUgCgkiL2Ljmc/mgd9/14bnLf5rWO
fWgAn0zwMWVlubF+/voflmamyKUymWTu
=Gy64
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New app-eselect category?

[Ulrich Mueller]

>>>>> On Tue, 26 May 2009, Fabian Groffen wrote:
>> We could move the 27 eselect-* packages to a new app-eselect category
>> (eselect itself would stay in app-admin).

> I hate package moves, so is it really *really* necessary?

Of course it is not necessary, only a matter of organisation (as most
package moves are).

Since there's also no agreement on the name of the category, let's
postpone it. Maybe the situation will be clearer after the release of
the Universal Select Tool.

Ulrich

Re: [gentoo-dev] New app-eselect category?

[Philip Webb]

090526 Ulrich Mueller wrote:
> We could move the 27 eselect-* packages to a new app-eselect category;
> eselect itself would stay in app-admin.
>> I hate package moves, so is it really *really* necessary?
> Of course it is only a matter of organisation (as most package moves are).
> Since there's also no agreement on the name of the category,
> let's postpone it.  Maybe the situation will be clearer
> after the release of the Universal Select Tool.

As a mere user who tries to keep track of his pkgs,
may I register a '+1' for keeping categories reasonably small
& for retaining the 'major-minor' syntax of the dir names ?
So the new category should help us users slightly
& 'app-select' looks like the most appropriate name for the new dir.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca