Re: [gentoo-dev] add global useflag: webkit
So we have 31 packages that can optionally support webkit, and none of them lets you choose between the qt and gtk branches at compile time. I fail to see the benefit of splitting the flag. --- Jesús Guerrero Botella El 07/05/2012 05:16, "Ben" escribió: > On 7 May 2012 08:47, Arfrever Frehtes Taifersar Arahesis > wrote: > > I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE > flags. > > I don't think that is necessary. > > Ben | yngwin > >
Re: [gentoo-dev] Please enhance your USE descriptions!
2011/3/31 Eray Aslan : > On Wed, Mar 30, 2011 at 04:41:25PM -0500, Dale wrote: >> +1 Some descriptions may as well not have one at all. May as well >> Google the flag and the package and see what, if anything, it returns. > > I would say working as intended. If you do not know what a package > does, chances are you don't need to enable it. And if you do want > to tinker, USE flags gives you enough of a hint to start googling. This has nothing to do with what you want to imply here. It's not about the tech skill of the user reading the definition. It's about the definitions being generic and vague enough so they can fit eight thousand packages that doesn't relate in any way, right? To say that the kde use flag gives "support for kde" says next to nothing to me on some packages. When I look into the ebuild and/or into the sources I can see all it does is to copy a .desktop file somewhere, or to enable the kde file dialog, or to create a window deco or a plasma snippet, or a phonon backend, or a color scheme. That's what I wanted to know and there's no way I can know it by looking at the USE description. > Having said that, we should at least have gramatically correct > English in descriptions. One might also lean towards more verbosity > in end-user oriented packages (versus server/backend/toolchain > packages). In any case, 10-15 words should be more than enough to > explain what a USE flag does. Mostly. But try cleaning the ffmpeg/libav-mplayer mess to decide which codec to use and you will find that a clear explanation (so you can decide) can't fit into that space. I don't have a problem reading ebuilds, though having to dive into the sources of a big package is another story, but I can understand users that find this an unpractical "solution". After all, if the USE descriptions doesn't tell a thing we should just remove them because they are taking space in our portage tree to provide zero info. So, "kde" flag purpose is to "enable support for KDE", oh, really?[/sarcasm] -- Jesús Guerrero Botella
Re: [gentoo-dev] Please enhance your USE descriptions!
2011/3/31 Tomáš Chvátal : > Well technically yep, but for lets say the ffmpeg the mp3 useflag means > "Enable mp3 encoding support." :) > > If user sets -mp3 it still can play mp3 tracks but in really worse > quality so it is just nice convinience that ffmpeg always allows playing > those files. > > Since i was that kind and disabled internal libmp3 that was first in > order of what would be used simply with -mp3 you will get mplayer > playing mp3 tracks but it is not desirable for you to do so. However, if I wanted someone else deciding what's "desirable" for me I wouldn't be using Gentoo, and I wouldn't care about USE flags at all. The only important thing here is that the label on top of the big red button doesn't match the purpose of the big red button. The final user doesn't really care if the USE is global or not, and s/he certainly doesn't care as much about the USE flag name as s/he can care about the USE flag purpose. On the other side, I remind everyone that there's bugs.gentoo.org which is where everyone should be reporting USE flag bugs instead of wasting the time here. Just like I do when I feel something is not right. Things usually get fixed.The last one that got my attention was the "symlink" flag for mplayer2, I reported it yesterday, now the fix is in the tree. -- Jesús Guerrero Botella
Re: [gentoo-dev] RFC: split up media-sound/ category
2011/6/21 Michał Górny : > Hello, > > As we discussed for a while, the media-sound/ category has grown very > large and it may be a good idea to split it. > > Right now, it contains audio players, editing software, converters, > sound systems and a lot of other utilities related to sound. Splitting > that up would make looking up software easier for users (e.g. if I want > to take a look at what audio players we have, I don't need to see all > other programs). > > What do you think? What new category/-ies do you suggest? I'd been always against the current classification. It's a bit confusing to me (it's just my -very subjective- view, of course). I'd gladly remove the "media-" thing as a whole, and do something like: gfx-viewers gfx-editors gfx-plugins gfx-libs sound-players (and maybe sound-radio) sound-editors sound-plugins sound-libs video-players (and, maybe, only maybe video-tv) video-editors video-plugins video-libs Then move fonts elsewhere or just leave them as they are. This is just a big picture though. I don't know if the degree of granularity that you get with (i.e.) sdl can be achieved with other libs, so some libs might fit into all of gfx-libs, sound-libs and video-libs. Just my random thought, as a mere long-time gentoo user. -- Jesús Guerrero Botella
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
audio-* sound better. graphics-* sounds better, if I suggested gfx it was just it's how we have it now in media-gfx (I never liked that either). I also think that media-* can stay. So, something like this would be closer, I guess. graphics-viewers graphics-editors graphics-plugins graphics-libs audio-players (and maybe sound-radio) audio-editors audio-plugins audio-libs media-players (and, maybe, only maybe video-tv) media-editors media-plugins media-libs As I said above, some libraries might not be easy to fit in a single category, so it might be necessary to just keep all of them under media-libs. I am not sure. What I'd really love would be to get a mechanism into portage so that a package can be in many categories at the same time because, well, is gwenview a viewer or an editor? Is kaffeine a media-player or a tv receiver? Is ffmpeg a media-lib, a sound-editor or a sound-lib? You get the idea. Roughly, one way to achieve this could be by using symlinks along with virtuals, but that's another entirely different thing. -- Jesús Guerrero Botella
Re: [gentoo-dev] RFC: split up media-sound/ category
2011/6/23 Kent Fredric : > On 23 June 2011 09:46, Zac Medico wrote: > > In order for this metadata to be of any use to a user, it would need > to have some way to facilitate its use, whether it be a fake generated > directory of symlinks, or a dedicated program ( like debians aptitude > ) for exploring this data in a tag-oriented way. The problem is that there's no official GUI for portage, and I don't think we should have that either. 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 the user, it will be a convenient way to look into media-tv, and find there all the tv players like kaffeine and mplayer that s/he would not have found otherwise. Even portage managers like portato will list the packages following the directory structure, so I think we should concentrate on that, rather than doing fancy things that won't be useful for a thousand years. Tags might be elegant, but I don't think they are practical for the average Gentoo user, which probably is the kind of user that sets USE="-semantic-desktop" to avoid using the whole kde tagging system. I also don't know if the advantages of tagging are really worth all the pain to implement. And after that, every Gentoo user will have to learn a new way to interact with portage when it comes to searching the package s/he needs. -- Jesús Guerrero Botella
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
2011/6/23 Duncan <1i5t5.dun...@cox.net>: > Jesús J. Guerrero Botella posted on Thu, 23 Jun 2011 08:15:44 +0200 as > excerpted: > >> Symlinks are clean, and portage has always been file-oriented so I see >> no problem with using them for this. > > It has been some years since I've seen the argument made, but if I'm not > mistaken, at least back in 2004-ish when I first switched to Gentoo, the > argument against in-tree symlinking (or multi-hard-linking, for that > matter) of any kind (other than the obvious directory hard-linking) was > that we wanted to keep the tree at least minimally deployable on non-Unix > filesystems like fat/ntfs. Note that while a user's profile uses a > symlink, the symlink is on /etc (which is thus implied to be a Unix > filesystem with symlinking capacities) pointing /into/ the tree, NOT > actually PART OF the tree. > > One scenario in which this might be a factor is that of someone doing > their syncs and source downloads at work where they have lots of > bandwidth available, then sneakernetting it home on a fat32 formatted > thumbdrive. > > Now it can be argued that the flexibility benefit of multi-category > packages trumps that of being able to put the tree on fat or whatever, > but there IS a definite loss of tree portability that's implied, and thus > a tradeoff to be considered. Yes, that's true. But it's also true that besides the symlinks, the portage tree will be broken the same moment you put it into a fat volume, because it will directly erase all the permissions and ownership metadata. So, the thing is already broken, why should we care if it breaks a bit more? Seriously, limiting ourselves because of an fs that not even MS uses any longer is not a smart thing to do, in my opinion. -- Jesús Guerrero Botella
Re: [gentoo-dev] RFC: split up media-sound/ category
2011/6/24 Zac Medico : > 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've personally never bothered to learn how to use external tools anyway, so I just navigate the tree using command line tools when I need to know something about a given package. I am sure I am not alone in that regard. I guess I could also "nano metadata.xml", ugh! Some portage GUIs also use this categorization scheme, like portato or porthole (not that they are important at all, but they illustrate the trend). Maybe it's just my mind model is archaic, but I can't really agree with tagging for massive trees. I wouldn't drop all my 40 thousand songs into a single folder and rely on tagging to keep them at hand. Portage has way more files so I don't see how tagging would be better for it than it would be for my music collection. I might be too much influenced by *nix (and DOS) OSes at this stage to be able to see the advantages of tagging (besides the decorative function), I admit. -- Jesús Guerrero Botella
Re: [gentoo-dev] RFC: split up media-sound/ category
2011/6/24 Ciaran McCreesh : > On Fri, 24 Jun 2011 09:52:03 +0200 > Jesús J. Guerrero Botella wrote: >> You might not like it, but Gentoo categories have always been >> directories, not words into metadata.xml. > > So tags are in some way related to categories then? For me, tags would be an abstract concept, related to A) categories (as in the current dir-based category concept) B) descriptions C) maybe, user tastes, so they should be flexible, just like id3 I see them as an instrumental and optional thing, but I don't think they should be the base of an fs-based system (because then the system wouldn't be fs-based, that is). -- Jesús Guerrero Botella
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
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, good look getting more than 65k files into a fat32 folder. Isn't that incongruence? Plus, if you truly do that, this should be called xmltagage, beucase it won't any longer resemble the bsd ports system at all. -- Jesús Guerrero Botella
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
2011/6/26 Kent Fredric : > 2011/6/26 Jesús J. Guerrero Botella : >> 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
Re: [gentoo-dev] RFC: split up media-sound/ category
2011/6/27 Zac Medico : > On 06/24/2011 12:52 AM, Jesús J. Guerrero Botella wrote: >> 2011/6/24 Zac Medico : >>> 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 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 ... ... .. . . . . :P Or boot usr lib home 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
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
2011/6/27 Wyatt Epp : > 2011/6/27 Jesús J. Guerrero Botella : >> 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 : >> 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
[gentoo-dev] Libreoffice without sane?
Hello. Today I discovered that libreoffice wants to install a dozen new dependencies. I understand that this is probably due to some modularization effort but I don't have a scanner and I don't plan to, so I am trying to hack the ebuild so sane can be enabled and disabled via an USE flag, but having no luck for now. Is there a way to completely disable sane in the LO build or is it a mandatory dependency? I found --with-system-sane-headers, which I guess is the way I'll have to go if there's no way to completely disable sane. At least I will save one dependency there. I am not saying it's a big win but it's a feature I'll never use. -- Jesús Guerrero Botella
[gentoo-dev] [k3b] KDE_HANDBOOK="always"?
Hello. How is it possible that this dependency became mandatory tonight for k3b? I don't think a handbook is a critical feature and k3b has been working like a charm for two years without it. Cheers. -- Jesús Guerrero Botella
Re: [gentoo-dev] [k3b] KDE_HANDBOOK="always"?
2011/8/11 Markos Chandras : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 08/11/2011 07:42 AM, Jesús J. Guerrero Botella wrote: >> Hello. >> >> How is it possible that this dependency became mandatory tonight for >> k3b? I don't think a handbook is a critical feature and k3b has been >> working like a charm for two years without it. >> >> Cheers. > Hi, > > Bug reports should really go on https://bugs.gentoo.org I know. All I want is to know if there's a reason why today, one year after the coming of k3b 2.0 to portage, that line has been added to the ebuild. There must be one, but I can't think of it myself. If no one gives any meaningful answer I'll file a bug, no doubt. I just wanted to gather all the information before opening an useless bug report. I already removed that from the k3b ebuild in my local overlay. I don't feel like recompiling the kde foundations for no reason and I definitely don't need the kde help center for anything. -- Jesús Guerrero Botella
Re: [gentoo-dev] [k3b] KDE_HANDBOOK="always"?
Thanks for the responses. I'll try to do better next time. Doubt cleared and I can continue using kde without being forced to install the help center. -- Jesús Guerrero Botella
Re: [gentoo-dev] Re: mesa r600 gallium news item
That would probably be a good idea. -- Jesús Guerrero Botella
