FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-27-2011, 02:19 PM
Jesús J. Guerrero Botella
 
Default RFC: split up media-sound/ category

2011/6/26 Kent Fredric <kentfredric@gmail.com>:
> 2011/6/26 Jesús J. Guerrero Botella <jesus.guerrero.botella@gmail.com>:
>> I am really amazed that someone didn't want to use links (a solution
>> with next to zero work involved) because they are not available in
>> fat32 (as if fat32 was relevant at all for us) but then people is
>> suggesting that we should put everything into a flat folder and use
>> tags.
>
> Well, the difference being "Symlinks are only really surplus utilities
> that make it easier for users" and "Some degree of backcompat" instead
> of "Core Functionality that will be required to make the code work".
>
> In theory, if you have the "most recent" versions of your package
> manager, after this change takes place, you will not need any symlinks
> at all, and functionality should still be retained if they were blown
> out completely.

The real question is why something that has been into POSIX since ever
can't be used for something that has also always been fs-based since
it was born (that's "portage").

I an not saying that this other system doesn't have it's advantages. I
am just saying that if I wanted a db-like-but-not-db-based system I'd
probably reinvent any .deb or .rpm based distro, rather than retouch
something based (even marginally) on BSD ports.

That still doesn't answer my question anyway: both features (symlinks
and +65k files on a single dir) are incompatible with fat32. And
someone said fat32 compatibility is a feature we want (still can't
guess why, but well, be consequent...). Obviously, we want fat32
compatibility when it comes to arguing against symlinks, which have
always been with us by the way, but that's not important when we talk
about other things that are not compatible with fat32.

Links seem to look not so elegant today, but we use them everyday for
eselect, /etc and even in the handbook. but Oh!, They are not that
good for portage.
--
Jesús Guerrero Botella
 
Old 06-27-2011, 02:23 PM
Jesús J. Guerrero Botella
 
Default RFC: split up media-sound/ category

2011/6/27 Zac Medico <zmedico@gentoo.org>:
> On 06/24/2011 12:52 AM, Jesús J. Guerrero Botella wrote:
>> 2011/6/24 Zac Medico <zmedico@gentoo.org>:
>>> On 06/22/2011 11:15 PM, Jesús J. Guerrero Botella wrote:
>>>> Symlinks are clean, and portage has
>>>> always been file-oriented so I see no problem with using them for
>>>> this. All we need is to deference the symlink to find the real name of
>>>> the package and put it in world instead of the symlinked name, so the
>>>> rest of packages won't even need to be retouched to fix the
>>>> dependencies. I don't really know if it's that simple as it sounds,
>>>> but it's an idea.
>>>
>>> For some reason, using symlinks to represent tags seems like an odd
>>> approach to me. I think it would be much more sensible to put them in
>>> metadata.xml or an ebuild variable. If for some reason you want symlinks
>>> representing the tags (I don't know why you would), you can always use a
>>> script to generate symlinks from metadata.xml files.
>>
>> You might not like it, but Gentoo categories have always been
>> directories, not words into metadata.xml. Most portage tools rely on
>> that. Not a strong argument, I know that. But someone used this
>> argument when someone else wanted to put portage into a database
>> instead of an fs-based tree. That was long ago, admittedly, don't know
>> if that conversation ever came up again.
>
> I see, so you want to optimize the tree layout for use with simple shell
> commands. For a shell-friendly alternative to metadata.xml, I suppose
> that we could instead use a plain text file called "tags" in the same
> directory as metadata.xml. If it listed one tag per line, you could use
> a simple shell command like this to search for packages with a specific tag:
>
> * find /usr/portage -name tags | xargs grep <tag name>

I still don't understand why

A) you need to build a project, a glep, whatever the course of action
is, I am bad at bureaucracy.
B) you need to code the solution, to fix What?
C) "ls $PORTDIR/whatever-category" is a command that's way simpler
than the one you posted.

XML seems to be the trend, but we should really think a moment, what's
what we are trying to fix?

We just needed to add some categories or rename them when someone
started this thread, but now, even when we know we are lacking dev
power in some areas we start arguing that the base concept of our OS
(portage) is wrong, and that we should redo it completely by putting
every ebuild into a directory and tagging them. Again, that's not
"port-age". Read on ports:

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

I don't even use tags for my music collections and now I am going to
be forced to use them to operate my OS. We might even end having
something like

<portage>
<ebuild>
.......................
</ebuild>
<ebuild>
.......................
</ebuild>
..
.
.
.
.

</portage>

:P

Or

<fs>
<dir>boot</dir>
<dir>usr</dir>
<dir>lib</dir>
<dir>home</dir>
</fs>

genpatches could also remove symlink stuff from the kernel, since it's
taking precious memory that could be used for the /proc.xml file. Yes,
feeling sarcastic, but I am really trying to understand what's what we
need to fix today.

--
Jesús Guerrero Botella
 
Old 06-27-2011, 05:59 PM
Wyatt Epp
 
Default RFC: split up media-sound/ category

2011/6/27 Jesús J. Guerrero Botella <jesus.guerrero.botella@gmail.com>:
> That still doesn't answer my question anyway: both features (symlinks
> and +65k files on a single dir) are incompatible with fat32. And
> someone said fat32 compatibility is a feature we want (still can't
> guess why, but well, be consequent...). Obviously, we want fat32
> compatibility when it comes to arguing against symlinks, which have
> always been with us by the way, but that's not important when we talk
> about other things that are not compatible with fat32.

I'm not sure where you're getting 65k files. Unless I misinterpreted
everything everyone else was saying, every package would still have
its own directory. There are fewer than 20k even with a bunch of
overlays installed. Regardless, you might check the other (other)
thread; I think we're probably going to go quick and
not-necessarily-dirty with sets to get 99% of what we're looking for
almost trivially.

2011/6/27 Jesús J. Guerrero Botella <jesus.guerrero.botella@gmail.com>:
> C) "ls $PORTDIR/whatever-category" is a command that's way simpler
> than the one you posted.
>
It's also fundamentally broken because one package can only be in one
category and their expansion has not historically been speedy. Tags
are a non-exclusive one-to-many relationship. So a package can have
as many tags as it needs, and users will be able to leverage tags
alone or in combinations to find things they want or need.

> I don't even use tags for my music collections

That's very curious, and I wouldn't mind talking about why that is
off-list (not quite joking; that's really interesting).

So to sum it up, we're fixing package navigation and discovery because
Gentoo is about choice. Even 15,000 packages is too many to have to
play "guess the category", and it's cruel to expect users (including
ourselves) to know everything in the tree at all times. It's in all
our best interest to make it easy to know what choices are available
so we can get back to more important things. Tags help further this
ideal.
 
Old 06-27-2011, 06:10 PM
Duncan
 
Default RFC: split up media-sound/ category

Jesús J. Guerrero Botella posted on Mon, 27 Jun 2011 16:19:57 +0200 as
excerpted:

> someone said fat32 compatibility is a feature we want (still can't guess
> why, but well, be consequent...).

I believe that "someone" that mentioned fat32 compatibility in the
context of symlinks was me.

But "we want" is rather strong for what I intended. More, "it's a factor
to keep in mind", and "if we decide we do NOT want to keep fat32
compatibility, we should be sure the feature we're implementing that
breaks it is worth the tradeoff."

Maybe it is worth the tradeoff. Maybe it isn't. But either way, we
shouldn't break that compatibility accidentally, simply because we didn't
think of it as a factor.

--
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
 
Old 06-27-2011, 10:03 PM
Jesús J. Guerrero Botella
 
Default RFC: split up media-sound/ category

2011/6/27 Wyatt Epp <wyatt.epp@gmail.com>:
> 2011/6/27 Jesús J. Guerrero Botella <jesus.guerrero.botella@gmail.com>:
>> That still doesn't answer my question anyway: both features (symlinks
>> and +65k files on a single dir) are incompatible with fat32. And
>> someone said fat32 compatibility is a feature we want (still can't
>> guess why, but well, be consequent...). Obviously, we want fat32
>> compatibility when it comes to arguing against symlinks, which have
>> always been with us by the way, but that's not important when we talk
>> about other things that are not compatible with fat32.
>
> I'm not sure where you're getting 65k files. *Unless I misinterpreted
> everything everyone else was saying, every package would still have
> its own directory. *There are fewer than 20k even with a bunch of
> overlays installed. *Regardless, you might check the other (other)
> thread; I think we're probably going to go quick and
> not-necessarily-dirty with sets to get 99% of what we're looking for
> almost trivially.

Well, someone suggested a flat directory, which I understand as having
all the ebuilds in a single directory, that's also why they are
talking about the need to make ebuild names unique, to avoid file
names collision.

> 2011/6/27 Jesús J. Guerrero Botella <jesus.guerrero.botella@gmail.com>:
>> C) "ls $PORTDIR/whatever-category" is a command that's way simpler
>> than the one you posted.
>>
> It's also fundamentally broken because one package can only be in one
> category and their expansion has not historically been speedy. *Tags
> are a non-exclusive one-to-many relationship. *So a package can have
> as many tags as it needs, and users will be able to leverage tags
> alone or in combinations to find things they want or need.

I wouldn't call that broken. Again, symlinks can perfectly solve that
with little extra work. We use them for that same purpose in lots of
things. For example, eselect sets symlinks to select the active mesa
implementation from between all the installed ones. And we have been
using symlinks to make libs and paths available with different names
in linux fs's since ever.

I am not saying that my idea is better than the rest. I am just
wondering why the heck symlinks are not an option when linux has
supported them natively since almost the day zero.

>> I don't even use tags for my music collections
>
> That's very curious, and I wouldn't mind talking about why that is
> off-list (not quite joking; that's really interesting).

Feel free to mail me if you want extra clarification. But to sum up, I
just keep everything in a estructured directory tree. I could easily
use easytag to automatically tag everything with little or not extra
effort, automatically, but I rarely resort to tags. I don't use
behemoths like amarok or the likes. I use mplayer or moc, usually. And
locate is the only tool I need to find quickly a song in less than one
second.

> So to sum it up, we're fixing package navigation and discovery because
> Gentoo is about choice. *Even 15,000 packages is too many to have to
> play "guess the category", and it's cruel to expect users (including
> ourselves) to know everything in the tree at all times. *It's in all
> our best interest to make it easy to know what choices are available
> so we can get back to more important things. *Tags help further this
> ideal.

That's fine by me, as long as some sense is retained in the underlying
fs estructure and tags are an added value, not a substitute for what's
already in there. What I wouldn't like is to get 140k ebuilds dumped
into a single directory.


--
Jesús Guerrero Botella
 
Old 06-27-2011, 10:25 PM
Paul Arthur
 
Default RFC: split up media-sound/ category

On 2011-06-27, Jesús J Guerrero Botella
<jesus.guerrero.botella@gmail.com> wrote:

> 2011/6/27 Wyatt Epp <wyatt.epp@gmail.com>:
>
>> 2011/6/27 Jesús J. Guerrero Botella
>> <jesus.guerrero.botella@gmail.com>:
>>
>>> That still doesn't answer my question anyway: both features
>>> (symlinks and +65k files on a single dir) are incompatible with
>>> fat32. And someone said fat32 compatibility is a feature we want
>>> (still can't guess why, but well, be consequent...). Obviously,
>>> we want fat32 compatibility when it comes to arguing against
>>> symlinks, which have always been with us by the way, but that's
>>> not important when we talk about other things that are not
>>> compatible with fat32.
>>
>> I'm not sure where you're getting 65k files. *Unless I
>> misinterpreted everything everyone else was saying, every package
>> would still have its own directory. *There are fewer than 20k
>> even with a bunch of overlays installed. *Regardless, you might
>> check the other (other) thread; I think we're probably going to go
>> quick and not-necessarily-dirty with sets to get 99% of what we're
>> looking for almost trivially.
>
> Well, someone suggested a flat directory, which I understand as
> having all the ebuilds in a single directory, that's also why they
> are talking about the need to make ebuild names unique, to avoid
> file names collision.

Packages, not ebuilds. Getting rid of categories puts all of the
packages in the same directory, so you need unique package names.
So you might make app-arch/par parchive, dev-util/par palm-par, and
app-text/par par. par-1.52.ebuild would still live in $PORTDIR/par/

--
Please do not ask the Staff to use red text to ask Users not to hypothetically
appeal hypothetical future bans.
--Cessna on RPGNet
 
Old 06-27-2011, 10:44 PM
Zac Medico
 
Default RFC: split up media-sound/ category

On 06/27/2011 07:23 AM, Jesús J. Guerrero Botella wrote:
> I still don't understand why
>
> A) you need to build a project, a glep, whatever the course of action
> is, I am bad at bureaucracy.
> B) you need to code the solution, to fix What?

Some people requested a "tags" feature. I'm not sure if "fix" is the
best word. Tags will provide a new way to search for packages, that's all.

> C) "ls $PORTDIR/whatever-category" is a command that's way simpler
> than the one you posted.

There are lots of possible approaches. See Ciaran's "Are tags just
sets?" approach that is very similar to your suggested symlink approach,
except that it represents a tag using a text file containing a list of
packages instead of a directory containing symlinks.

> XML seems to be the trend, but we should really think a moment, what's
> what we are trying to fix?

Again, maybe "fix" isn't the best word. I believe that the goal it to
provide a new method of searching that is based on tags.

> We just needed to add some categories or rename them when someone
> started this thread, but now, even when we know we are lacking dev
> power in some areas we start arguing that the base concept of our OS
> (portage) is wrong, and that we should redo it completely by putting
> every ebuild into a directory and tagging them.

I would advise against going down the "redo it completely" path, since
it's relatively easy to implement a tagging mechanism that will coexist
with the existing category framework.

> Again, that's not "port-age". Read on ports:
>
> http://en.wikipedia.org/wiki/FreeBSD_Ports

Interestingly, the wiki page that you linked has a link to a project to
add tags to the ports collection:

http://www.tobez.org/port-tags/

> I don't even use tags for my music collections and now I am going to
> be forced to use them to operate my OS.

Again, I would advise against going down the "redo it completely" path
that this statement implies, given that it's relatively easy to
implement a tagging mechanism that will coexist with the existing
category framework.
--
Thanks,
Zac
 

Thread Tools




All times are GMT. The time now is 06:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org