Re: [gentoo-dev] pending dooooooom of use.defaults
IMHO a lot of the auto-use stuff that is "mis-used" is moreso what IUSE defaults is for. I have a crappy patch for IUSE defaults that I may try to work on so that it can be merged in the 2.1/2.2 branch. I realize that this is probably a bit far off, but will hopefully improve the situation. Of course at that point we can dump the crappy nocxx flags too ;) solar wrote: On Fri, 2006-01-13 at 06:57 -0500, Mike Frysinger wrote: as one of the new sane features of the next portage-2.1_pre release, we're looking to cut out use.defaults support I see this as a good and bad thing. Good in one hand that less autojunk would be enabled like python/perl bindings not being added to every program on your system that supports it. Bad in the other hand I see the state of profiles getting worse=more bloated. The autouse itself is not a bad feature or idea if it were used properly. Problem is that it's not been used properly. If it were limited to simple things like just X and the things that actually make sense then it would even be fine to keep and would allow some of the more bloated (default-linux) profiles to be cleaned up. Shrug. I like the existing behavior and the power of deciding for myself when and where I want to take advantage of USE_ORDER= existing stable users wont be affected as the 2.0.x versions will continue to carry support for this, but some of you stable users may notice some USE flags suddenly "disappearing" to recap, use.defaults inserts USE flags for you based upon what packages you have installed when you havent declared a preference. for example, if you have neither '-cups' or 'cups' in your USE (either in your make.conf, profile, env, whatever), but you do have the net-print/cups package installed, portage will add 'cups' to your USE -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
Can we get this on the website/announce? I agree that auto-use is the
suck and that it needs to die a long excrutiating death, but I think a
lot of users will be like wtf when 2.1 hits stable and --newuse turns up
a massive crapload of packages.
Whether this announced now, or when portage-2.1 hits stable, or both, I
don't really care. If you need a ditty to post about it we can probably
whip one up.
Mike Frysinger wrote:
On Friday 13 January 2006 11:15, Kalin KOZHUHAROV wrote:
Or is it because I always had:
USE="-* ${MY_USE}"
in /etc/make.conf?
yes
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Thoughts on the whole gentoo future discussion
Matthew Marlowe wrote: Hi all, The following are just my opinions/summaries: 1) It appears that the most dissatisfied devs are those who have been proponents of the "enterprise" aspect of gentoo. When they say that not much has been accomplished in the last 2 years, I think you have to look at it from the enterprise point of view. GLEP19 never got anywhere. Other than small improvements, I'm not sure anything positive has happened. If anything, Gentoo appears to be heading more in the "desktop" and "hobbyist" direction. That might be what they mean when they say gentoo is becoming irrelevant. And who is responsible for making those "enterprise" aspects of Gentoo a reality? If you can't sell your idea to the other developers then you are stuck doing all the work yourself, and I think part of that is just how things are. I make references to Portage because that is the team with which I am intimately familiar. Including Enhancement requests that are marked RESOLVED LATER due to them being completely out of scope for the current codebase we have ~360 open bugs. At least when I look at those bugs I try to order by triviality first, then by interest, and when the insane moments strike me, by importance. Granted, I am not a Gentoo Portage Developer, but I attempt to help out when I can. If you need something and it's trivial, or I find the concept interesting or fun I'll probably try it out, most likely right then, but if it's something difficult, especially something that would just be a huge PITA to do with the 2.0 codebase, then it probably won't get done anytime soon. So are you going to blame me for not implementing the stuff you want? Is it my fault that I'm not properly motivated to implement your features? You can't blame the whole community for not implementing what you want, since the responsibility for getting it done is essentially your own. That being said, I haven't heard any noise recently about GLEP 19. Maybe I'm in the wrong channels? Perhaps you need to reshape and resubmit the GLEP. Part of having the community work with you is letting the community mold your idea. I enjoyed the whole emerge news GLEP ( although Ciaran seems to dislike my mails ;) ) because I knew in the end we would have a well rounded GLEP that suits everyone. Alec Warner (antarus) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: regular project updates
Patrick Lauer wrote: Hi all, as the debate about the future direction of Gentoo continues it's getting more and more obvious to me that there's a lack of information skewing the debate. It seems that while most devs (and users) have a good idea what's happening in "their" projects it's quite difficult to see what is happening in other projects. So - as GWN monkey - I'm offering my services as aggregator for project updates. Maybe someone from the doc project wants to help to get this information put on the website so that it's visible? I suggest project updates every 6 months (which roughly is the same timeframe as releases) Maybe this helps people get a "global vision" of where Gentoo is and where it's going. Any feedback appreciated :-) wkr, Patrick I would prefer quarterly, but anything is better than the present. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] December 15th Meeting Summary
Marius Mauch wrote: On Thu, 15 Dec 2005 22:47:21 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: this months meeting wasnt too eventful, kind of quiet ... on the agenda: - Marius: decision on multi-hash for Manifest1 there was a bit of hearsay about why the council was asked to review/decide on this issue since we werent able to locate any portage devs at the time of the meeting ... Well, it would help if the actual meeting date would be announced and not pushed back without notice ;) so our decision comes with a slight caveat. assuming the reasons our input was asked for was summarized in the e-mail originally sent by Marius [1], then we're for what we dubbed option (2.5.1). that is, the portage team should go ahead with portage 2.0.54 and include support for SHA256/RMD160 hashes on top of MD5 hashes. SHA1 should not be included as having both SHA256/SHA1 is pointless. Ok, not a problem. it was also noted that we should probably omit ChangeLog and metadata.xml files from the current Manifest schema as digesting them serves no real purpose. You're all aware that this would break FYI, that version of portage is already broken by the virtuals glep and X11's virtual/stuff so no harm there ;) -Alec Warner (antarus) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
Jakub Moc wrote: 22.11.2005, 20:57:15, Chris Gianelloni wrote: The idea was to move out the stage1/stage2 docs to somewhere else. Then create some sort of "Advanced Installation Topics" guide or something, to list out the replacement procedures for customizing a system from a stage3 tarball, then, eventually, drop the stage1 and stage2 tarballs. Erm, did you read what solar wrote about hardened stages and why should stage1 still stay? I was working on the idea of doing it all in stages. The "problem" occurred from people freaking out because they didn't bother reading the entire news blurb that tells exactly where the instructions moved to, plus links to the bug # and discussion. There's also this nice section in the Handbook. I'd point out that this was not well executed as a major change should have been. We talked of major package changes, apache config changes, of package breakage. Then one day you up and remove what some consider a vital part of installing with no warning. Announcements earlier noting the pending removal of tarballs to say, g-announce and this list would probably have stifled much of the complains ( see the news hit gentoo-wiki, gentoo-portage, and the community ). Otherwise yeah, you will get a knee-jerk reaction, many users think you just screwed them out of something. Nevermind the fact that they are wrong and uninformed ( in most cases ) you did a crappy job of conveying the message of what when and why. "A stage3 tarball is an archive containing a minimal Gentoo environment, suitable to continue the Gentoo installation using the instructions in this manual. Previously, the Gentoo Handbook described the installation using one of three stage tarballs. While Gentoo still offers stage1 and stage2 tarballs, the official installation method uses the stage3 tarball. If you are interested in performing a Gentoo installation using a stage1 or stage2 tarball, please read the Gentoo FAQ on How do I Install Gentoo Using a Stage1 or Stage2 Tarball?" That FAQ section has nothing in common with the original stage1 docs. Sorry, installing stage3 to remove all the use flags cruft subsequently, bootstrap and re-emerge the system and then ponder which packages are not needed any more (again, there's no reliable tool to remove unneeded stuff from system, I've already mentioned this once) - hmmm... :/ And - once stages 1+2 are removed (as you are suggesting above), then I'll install the system only to build my own stage1 w/ catalyst, then reformat and start over with my own stage? Ah, that makes live sooo much easier ;p Personally if releng is already making stages 1 and 2 for the liveCD's I see no reason not to give that work away to the community. Stick it in some unsupported/ section on the mirrors and tell people so. Why throw away the work you did making the liveCD? Can you quantify the number of bugs here? -Alec Warner (antarus) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] FEATURES=test and the internet
So who do I have to bribe to get my packages on the bad QA list? :) On Thu, 17 Nov 2005, Mike Frysinger wrote: > On Thu, Nov 17, 2005 at 02:38:13AM +, Dan Meltzer wrote: > > However, I've seen a few packages that fetch stuff during the test > > phase from the internet > > if you have any packages other than libxml2 that do this, you should > file bug reports about each one > -mike > -- > gentoo-dev@gentoo.org mailing list > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Creation and handling of virtual/tar
Diego 'Flameeyes' Pettenò wrote: On Monday 07 November 2005 19:22, Donnie Berkholz wrote: Sure. What's the point? What benefit does one tar have over the other? How is bsdtar more capable in any situation than gnutar? the first point is not to change the default behavior of an userland, so FreeBSD should have FreeBSD tar. About the difference between the two, I still prefer bsdtar because is a little more cleaner (imho), it does not use gzip/bzip2 in pipe to extract .tar.gz and .tar.bz2 archives, and it extracts zip files and iso files. And it's a choice people can do, default users won't see any difference anyway. So why is a virtual needed? Don't the two packages co-exist? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Jason Stubbs wrote: On Friday 04 November 2005 23:26, Xavier Neys wrote: Nathan L. Adams wrote: One source: http://errata.gentoo.org/ Push that out to as many alternate sources as you like (RSS feeds, summaries in emerge --news, forums post, etc.), but make it known that the website is *the* source (your alternate sources should point back to it). I beg to differ. The tree should be the central point because it's the only known place where all users can receive relevant information on and for each and every system they maintain right before they upgrade. The warning and the logic that triggers its display should be part of Portage. Sometimes, all that would need to be displayed is "run foo to fix bar" or "Please do read http://bleh _before_ you upgrade foo". If an "Upgrade guide to foo/bar for Gentoo" is required, you need an author to write it, not extra code or an extra web site. I probably shouldn't have included the sarcastic comment in my only other reply to this thread, but the rest of it was completely serious. People are under the mistaken impression that the ebuild tree is required to use portage. This is wrong and will become more and more wrong as time goes by. If there is not a specific need for this news stuff to go into the tree then it shouldn't be there. If there is a specific need (ie. it is tied to packages) what difference is there to the existing ChangeLog? -- Jason Stubbs I am going to summarize a bit, and address your point. Summary: people want small news tidbits to be distributed to all users. Currently the suggestion is tree-based. Portage should have code to detect news elements after a sync and copy relevant elements to a uesr specified news directory. The news should be in a human readable format (XML, RST, pig latin, don't care at this point see below). Portage should post-sync, print a message noting the number of unread but relevant news messages. Users can use whatever means of reading them that they like. IMHO, emerge --news can go to hell in a handbasket, I'd rather just friggin use less, but hey, if you write the code... News messages should contain minimal information necessary to carry relevant information including affected packages, and a link to some sort of documentation, be it gentoo-wiki, or official package docs, or whatever. For those without internet access 24/7, there may be an option required to fetch these links. In the case of say, dial-up where someone only has network say, 4 hours a day, they may wish to sync their tree, and spider the docs links so they may view them locally. Machines with no outside network ( internal production servers ) may also wish to make use of this. In the case of online guides, we cannot necessarily define their content, it may be XML, it may be plain text. I do not see how conceeding that a user may need a web browser SOMEWHERE, is that big of a tradeoff, especially if the content is already locally available. As far as including news in the tree goes, news is repository bound information. Each repository may in fact have relevant news, and in preparation for multiple repositories this is how the news should be handled. It goes with the rest of the repo-specific information. That is why it should be in the tree. However, in the case of a remote tree, some extra API calls may be required. However, it is up to the class implementor to implement those calls, not the original portage team ( unless you want to support remote trees yourself, in which case that duty falls to you ). The only other thing was no tree but a binpkg repo, in which case in savior, binpkg repo should have news elements build in ( a repo, just all built packages ). In stable, news should probably be added to the binpackage if it's listed in the packages-affected. For the XML vs RST. I personally don't want to read XML files in a console, or install anything that makes it look all pretty for me, RST is plenty good enough. Since Ciaran has graciously written all the code for it already, I don't see any reason not to use it. RST is pretty simple to migrate to a new format anyhow, and a converter could be easily whipped up to transform it to guideXMl for errate.g.o if that is what is desired ( not a bad idea IMHO ). I forgot one other thing, that being perhaps a red NEWS that shows up next to affected packages during an emerge -pv , informing you that important news is available for a package you are about to install. So yeah, this is a long thread :0 Alec Warner (Antarus) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
Andrej Kacian wrote: On Tue, 1 Nov 2005 18:18:55 + Ciaran McCreesh <[EMAIL PROTECTED]> wrote: | Before this, make pre-install and post-install emerge messages more | usable, instead of having them lost among thousands of gibberish text | in batch emerges. Separate issue. That one's the whole elog thing. Yes, it is a separate issue, but it's an issue that's been around for far too long, and seems to be ignored, despite the apparent importance of emerge messages for users. http://search.gmane.org/search.php?group=gmane.linux.gentoo.portage.devel&query=elog The first 7 or 8 results should about cut it. As for it taking forever, code doesn't write itself, and 1000's of whining users/devs don't get code written either. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Reminder on dependencies.
Ciaran McCreesh wrote: On Tue, 25 Oct 2005 11:16:54 -0600 Joshua Baergen <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | >RDEPEND lists the things that are needed to use a package once it is | >installed. | | Maybe RDEPEND is insufficient to properly describe a library | package. I see a big difference between using and compiling against | a library. I realize you need to compile against it to use it, but | that's certainly not a run-time dependency. Well yes, we already know we need a few dozen more new dependency atoms. But we're dealing with "what we can use currently" here, not some hypothetical future situation. So define what you need to meet your goals, hell define your goals and agree on them ( or at least a subset ). Right now you are just arguing back and forth over this small issue. What other issues does the current system impose? What do you suggest to fix them? What manner of "few dozen more new dependency atoms" are needed and what do they do? How can you reconcile the goals of compiling against library headers vs embedded's space need? With the ideal case decided you can A. Move gentoo to get closer to that case; and B. Know the deficiencies in the current implementation. Right now it just looks like a bunch of people bickering over a policy issue. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] modular X - 7.0 RC1
Dan Armak wrote: On Thursday 20 October 2005 21:48, Kevin F. Quinn wrote: On 20/10/2005 21:16:47, Dan Armak ([EMAIL PROTECTED]) wrote: On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote: On 10/20/05, Dan Armak <[EMAIL PROTECTED]> wrote: To solve this issue it would have to be an on-by-default flag, i.e. 'noxserver'. I know some people are strongly against nofoo flags. What about an off-by-default 'xserver' flag? It wouldn't solve the problem at hand. Without any flag at all, the user needs to 'emerge xorg-x11' manually to get eg KDE to run locally. With an off-by-default flag, he needs to set it on manually, _before_ installing KDE, to get an xorg-x11 server. As long as he needs to do something manually, explicitly, it should just be an 'emerge xorg-x11', which after all is a very simple operation. Maybe I'm being stupid, but I don't understand why a user would need to emerge xorg-x11 manually when doing 'emerge kde'. Surely somewhere in kde's dependency graph the X server is called up in RDEPEND? An X server is clearly a run-time dependency. Like, konqueror RDEPENDS on qt which RDEPENDS on xorg-xserver, or whatever. No, KDE (like all X11 apps) only needs the client X11 libs and headers. It can then contact a remote X11 server over the network. Now that the client libs and headers are available in separate ebuilds, there's no reason for KDE to depend on the server ebuild, so it won't. Take the X use flag out, since X is horribly not descriptive. Xclient, Xserver, both tell you what they are doing, both probably global use flags. Announce it loudly, and fix everything at once, since that is probably how it will go anyway :) I think it's really cool to be able to build a server that has no X, but has KDE on it, especially since 99% of the time I'd never actually log in locally. There is nothing wrong with 2 flags here, IMHO. Yeah you have to set them, either in default-linux/$arch ( not base here however, set it higher up, not everyone wants friggin x installed *shakes fist* ) or wherever. That or auto-use, either way people using -* are screwed, we know this and they know it. It's something they deal with every day. I dout their system is going to be horribly screwed as long as they are paying attention. If they randomly --depclean without looking, then yeah X will probably get ripped out from under them :) Thats their risk. (antarus) -Alec warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Just another portage enhancement idea...
FYI elog is implemented in CVS ( 2.1 ). When it will be released is anyone's guess. Kevin F. Quinn wrote: On 11/10/2005 9:18:41, Dave Nebinger ([EMAIL PROTECTED]) wrote: This is probably the fifth time at least that I've been bitten by this... https://bugs.gentoo.org/show_bug.cgi?id=11359 [NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [Summary] tentative x86 arch team glep
Ciaran McCreesh wrote: On Tue, 06 Sep 2005 18:03:37 +0100 Ed W <[EMAIL PROTECTED]> wrote: | As an "outsider" reading that summary the message *I* read is that | there is some strain over fitting the development model into | "stable", "~", and "package.mask". I think I see people basically | saying that they have differing views over what qualifies for each | level? The system basically works. The problems are: * It's not always used correctly. * It's not entirely understood by some users. * Some users think it should be easier to unmask a group of related packages. The third one's invalid, they just need to learn how to use sed... This is a lack of tools, not everyone needs to learn sed. Just 1 person needs to write the tool to do the job ;) No, I'm not volunteering. -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New global USE flag: logrotate
Ciaran McCreesh wrote: On Tue, 02 Aug 2005 09:48:25 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: | Tom Martin wrote: | | Hi list, | | | | Bug 97447 wants a logrotate USE flag, which is used by about five | | packages locally. Unless there are any objections, I'll globalify it | | later today. | | I think this flag is a bad idea. Why should I have to recompile a | package to get some files that go in /etc? Either install them | unconditionally or don't install them at all. Files in /etc are expensive in terms of sysadmin time. The only things in /etc should be things that are both necessary and likely to be modified by a sysadmin. And who makes that call, shouldn't the sysadmin decide what is necessary in /etc and what is not? Why shouldn't portage just install stuff in /etc and let the sysadmin figure out what needs to be there via INSTALL_MASK? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Hold on portage feature requests
Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Stubbs wrote: | The reason behind this is that at approximately two thirds of bugs received | are feature requests and they are drowning at the real bugs. More importantly, | the critical bugs are becoming very hard to keep track of. This, at a time | when we are focusing on fixing major and critical bugs only so as to get the | next version completed quicker. Are you having a tough time filtering out enhancements in your queries or something? I don't understand how feature requests could possibly interfere with anything besides other enhancements. Many of the enhancements aren't marked as such, dev-portage has a lot of bugs ( I've been watching it for 4 months ) and they are varied, old and extremely difficult to manage at present. As long as the bugs are still in bugzilla I din't see a problem with them being closed. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC6QZgXVaO67S1rtsRAqkKAJ4+/fQUkkYaUOXVmYGobLTRh+tHeACcDnHU ZsYj4ABIrHcnoYHzLPOWmu4= =36q7 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changelogs
Maurice van der Pot wrote:
On Tue, Jul 26, 2005 at 10:05:49PM -0400, Alec Warner wrote:
Recent discussion on this ML and on the portage-ml as well as
#gentoo-portage regarding pkg_warn() and the basic concept behind it.
We talked about adding new functionality, about adding a warning section
to the ebuild or to the metadata. However. all of these tend to have
problems.
The dev won't write the extra function,
In your proposal this would be "the dev won't write the extra changelog
content" and ...
duplication of data in pkg_{post/pre}inst,
... "duplication of data in Changelog/pkg_post".
mangling of metadata.xml.
I don't know what this means, but I don't think pkg_warn has this
problem.
So I don't see any advantage of putting it in the changelog. I actually
like the pkg_warn idea much better.
So tell me again, what does your proposal solve of the problems you see
with pkg_warn?
-l support for reading changelogs is already in portage, pkg_warn
support would only be in CVS which won't be out for a long time(*), and
pkg_warn() doesn't fit in with the rest of the ebuild functions. This
solution is done now, in the changelog, to be viewed by users. Metadata
ideas were not liked because metadata is not versioned and the parsing
would not be easy.
* Long time being whenever, not starting a flamewar about it.
Regards,
Maurice.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Changelogs
Simon Stelling wrote: Alec Joseph Warner wrote: to get you upgrade information. While I can see a great benefit in putting important information into the changelog, I really can't see why portage should provide functions to read a changelog, when nearly all packages provide the same information on their homepages. Because the functionality already exists and is in stable portage? Because some developers maintain system critical packages that can cause large amounts of breakage and get complaints from users when things break? Gentoo is a distribution and there is some responsibility to provide users upgrade paths when packages switch versions. Gentoo isn't just portage, IMHO. Note, we're talking about upstream's changelog, not portage's one. There is no feature to read upstream's changelog through portage *before* merging it. I agree that Gentoo is more than Portage, and it definitively should provide upgrade paths where necessary, but not by implementing such a feature. It's far easier to stick a note into the Changelog/post_pkg() saying "There were major changes in this release, please carefully read the changelog at http://www.upstream.org/."; A. In some instances, those notes never show up in the changelog B. pkg_postinst() doesn't cut it, because the damage is already done in that phase. I would be very supportive of A. Just a note in the gentoo changelog saying Warning: this upgrade could cause problems, see the project homepage for details. Right now it is not always possible to destinguish between a safe upgrade and one that the developers know is dangerous. I am simply advocating a standard string in the changelog ( so that it's grep-able ) warning the user about potential problems. No long speeches in the changelog about it. Regards, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Changelogs
Simon Stelling wrote: Hi, Duncan wrote: and see what's up, or one can visit the website and check it out there, but for such a critical part of a Gentoo machine's infrastructure, one would certainly wish for something a bit easier than either of these. Erm, is that a joke? You want an easier way than browsing to a web page and read? Why should portage go different ways than every other software project? Expanding on the idea a bit further, what about creating a generic "emerge changelog" function, that fetches the tarball if necessary, then extracts only the changelog, and opens it for viewing (presumably using the $PAGER environmental variable to determine what to display it with)? Naturally, given Gentoo can't control the upstream changelog format, enforcing parseability rules as it does for its own, the entire changelog would of necessity be displayed, leaving the user to figure out the relevant cutoffs instead of doing it automatically as emerge -pl does with the portage tree changelogs, but it'd still be a rather easier way to view upstream changelogs before installation (or for that matter, after) than we have now. Portage is a package manager. package managers have to manage package versions and their dependencies. They do NOT have to be fancy changelog readers. As you already stated, it's not the developers responsibility to get you upgrade information. While I can see a great benefit in putting important information into the changelog, I really can't see why portage should provide functions to read a changelog, when nearly all packages provide the same information on their homepages. Because the functionality already exists and is in stable portage? Because some developers maintain system critical packages that can cause large amounts of breakage and get complaints from users when things break? Gentoo is a distribution and there is some responsibility to provide users upgrade paths when packages switch versions. Gentoo isn't just portage, IMHO. Additionally, if you really have to read the changelog before emerging the new version, the information is really important, and I'm sure it will show up in portage's changelog. Please don't make portage a news reader. Regards, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
Caleb Tennis wrote: 2. You'll force a user to upgrade to qt 3.3 if they attempt to install any package that depends on Qt. Speaking from personal experience, I still have some servers using Qt 3.1 because I have programs running 24/7 that rely on Qt and simply cannot be upgraded right now. You don't force anyone to do anything. If they don't want to upgrade because they can't then they can p.mask the programs they can't upgrade. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] cleaning out 'bc' and 'ed' from system
Philip Webb wrote: 050421 Juha Varkki wrote: 050421 Mike Frysinger wrote: we've had 'bc' and 'ed' around for historical reasons and because we've never actually tracked what packages invoke them Do you mean /usr/bin/bc or did I miss something? Why on earth are you taking it out? I use bc quite often actually .. surely the idea of 'system' is to provide all those basic tools which someone might need when doing sysadmin things without X . that's why Lynx is included, to allow seeking WWW help & downloading things. Ed is there because it's needed for Sed, which is useful for sysadmin; Bc has a similar usefulness. all at basic console level. as they say, if it ain't broke, don't fix it: try to understand why it was done that way originally. IIRC, "System" is the set of minimal packages required to get the system running. Lynx is not in system ( although on the liveCD so one can view/download web material while on the liveCD ). "System" has nothing to do with administrating your system. Thats your job as the administrator, to have all the utilities installed that you require. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] cleaning out 'bc' and 'ed' from system
If someone is willing to do the work and not fsck things royally I don't see a big deal about it. If nothing in system depends on it then it shouldn't be there, we can trim 250kb off of all our stages and liveCD's. Embedded gains 250kb off of their stuff as well. I just don't want to see giant h0rkage in the tree because the person doing the work didn't do a good enough job. *mutters something about tree changesets*. Luis F. Araujo wrote: No. I just don't see the point to unnecessarily remove a package of 249.72 KB that might be very tricky to find out all of its dependencies and will lead to (unnecessarily) ebuild rewriting. bc is the kind of application that has been around long time enough to cause tricky problems, that's fine ... as long as it isn't unncessarily. -- gentoo-dev@gentoo.org mailing list
