View previous topic :: View next topic |
Author |
Message |
btrotter n00b
Joined: 06 Oct 2005 Posts: 9
|
Posted: Sat Oct 08, 2005 2:11 pm Post subject: |
|
|
Hi,
Kloeri wrote: | btrotter wrote: | This reason is totally broken. A simple "warn users of config changes if updating" flag (with an addition URL for more info) or a similar simple system, should be easy to add to portage. Setting this flag would be much easier and much more effective than sending out emails on the mailing list (which I assume also requires a superhuman amount of effort???). |
We're not going to break the emerge chain on purpose for no better reason than users not caring enough about their updates and being caught with their pants down so to speak. Portage is not supposed to do any needless handholding if it gets in the way of users paying proper attention. |
Paraphrasing my last post: "The optional option should be optional. The option should not break the emerge chain, but probably will because of unrelated bugs that aren't related (bugs that should probably be fixed sooner or later anyway)."
If people are smart enough to do "emerge -pv world" first (which IMHO isn't a problem), and if the developers are smart enough to implement this so that "emerge -pv world" also displays any warnings (which I'm honestly unsure about), then there wouldn't be any problem.
PaulBredbury wrote: | btrotter wrote: | This reason is totally broken. A simple "warn users of config changes if updating" flag (with an addition URL for more info) or a similar simple system, should be easy to add to portage. Setting this flag would be much easier and much more effective than sending out emails on the mailing list (which I assume also requires a superhuman amount of effort???). |
Are you volunteering for this documentation/administration task? I count 20,597 ebuild files (i.e. *.ebuild - versions of packages) in my /usr/portage, for 10,179 packages. Assuming you're totally dedicated and efficient at this task, take 20 minutes per ebuild file, work an 8-hour day for 5 days a week, and take no other holidays or breaks, it will take you 3.3 years of continuous effort to document all the ebuilds in this simplistic manner. I'm sure we'll all be grateful, and won't moan at the end that we still have to read some of it, and do some work ourselves, to configure and maintain our systems. |
Obviously all of the ebuilds that do not need this flag (or whatever) set, would not need this flag (or whatever) set. Therefore the only ebuilds where this flag (or whatever) does need to be set are those where the flag (or whatever) does need to be set.
Based on what I've heard here, developers are already finding the ebuilds that will cause problems and sending out different announcements on different mailing lists in a less than perfect attempt to let people know beforehand, and then spending more time fixing up the mess when people have failed to read the announcements. This entire process would be far more time consuming than setting a flag (or whatever) instead.
Does anyone here understand the difference between polling and IRQs? The idea behind polling is that the CPU spins in a loop until the device is ready, continually wasting CPU resources. The idea behind IRQs is that when the device needs attention it interrupts the CPU, so that CPU cycles never need to be wasted.
This issue is the same thing. The developers expect "good sys-admins" to waste time continually checking for announcements and reading them, while others would rather have portage let people know when attention is needed.
I can't see what can be gained from forcing all users to waste their time checking for announcements, etc when it would be much easier and much more effective to avoid wasting peoples time. Let's see - a thousand "good" sys-admins spending 4 hours a week at a cost of $20 per hour adds up to over 4 million dollars wasted per year. Does this figure give the Gentoo developers some form of perverse pleasure?
Cheers,
Brendan |
|
Back to top |
|
|
llongi Retired Dev
Joined: 15 Apr 2004 Posts: 459 Location: Switzerland
|
Posted: Sat Oct 08, 2005 3:10 pm Post subject: |
|
|
btrotter wrote: |
I can't see what can be gained from forcing all users to waste their time checking for announcements, etc when it would be much easier and much more effective to avoid wasting peoples time. Let's see - a thousand "good" sys-admins spending 4 hours a week at a cost of $20 per hour adds up to over 4 million dollars wasted per year. Does this figure give the Gentoo developers some form of perverse pleasure?
|
You can't even imagine the sort of pureley sick pleasure we feel.
A) Building up knowledge is never a waste of time, and if we make the announcement directly in Portage (wich we did, ebuild warned you!), it would not change: the change would still happen, you would still need to update your stuff/change it, and probably if we did that, no one would read it! You don't read changelogs, you don't read the distro's ML, site, forums, blogs, anything, why should you read that? Why should the people who indeed _do_ read stuff instead be penalized, with broken emerge chains, need to set special USE flags etc.?
B) Math is beautiful, let's see - 1000 "good" devs spending 16 hours a week at a cost of $20 per hour adds up to over 16 million dollars they won't ever see per year. Does this figure give the users some form of perverse pleasure? Knowing that people work their ass off, with absoultely _no_ retribution, and then get bitched about not doing their work right and that what they do can/will/lets the users loose money? So the idea is "they work for free, and then when I use their product, provided by them for me for free, I will bitch about the fact that what they just did lets me loose money and time" ? This is _really_ sick and perverse if anyone thinks something like that!
Best regards, CHTEKK. _________________ Best regards, Luca. |
|
Back to top |
|
|
fuji Tux's lil' helper
Joined: 26 Apr 2002 Posts: 111
|
Posted: Sat Oct 08, 2005 3:42 pm Post subject: |
|
|
Kloeri wrote: | If anybody can come up with a good solution to the problem that doesn't require needlessly breaking the emerge chain I'd love to hear about it. enotice and portage spitting out warnings/infos after all the merges finishes would be a small step on the way but that's the best I can think of currently. |
Why not flag an ebuild with important information and then do what `emerge -Ca [pkgname]` does by waiting 5 seconds before continuing. Or, try `emerge --depclean` and see how portage already displays important information. The important information can be fetched from /usr/portage/UPDATING so it's only written in one place.
Add a new option to emerge '--einfo' which will display einfo text. That way we could `emerge -{a,p} --einfo apache` -- Then launch a campaign for it's use on the forums, like the devs did against the -U option.
And, why not use the UPDATING file.
We could even add a new flag to the `emerge -p` output, something like 'I' which could mean important information. The same place there is N for new, S for new slotted, U for updating, etc.
Use every method available to you to create the effect you want. How many ebuilds go through these changes that change your system? Once a month? How much work would it take to flag one ebuild a month? The work is implementing the system, but I'm sure it'll benefit portage in the longrun.
Figure the upcoming update to python would also be a good ebuild to be flagged under this system. All a dev would have to do is flag an ebuild for some of the options, the other would require an addition to emerge for the --einfo flag.
In fact, the flag could go into the variable RESTRICT. _________________ Came for the hype, stayed for Portage. |
|
Back to top |
|
|
j-m Retired Dev
Joined: 31 Oct 2004 Posts: 975
|
Posted: Sat Oct 08, 2005 3:54 pm Post subject: |
|
|
btrotter wrote: |
If people are smart enough to do "emerge -pv world" first (which IMHO isn't a problem), and if the developers are smart enough to implement this so that "emerge -pv world" also displays any warnings (which I'm honestly unsure about), then there wouldn't be any problem.
|
Most people in this thread can't be bothered to read emerge --changelog output, and they equally would not bother to read emerge --upgradenotes or whatever, b/c there's too much noise and they have better things to do with their time or they did not know that there's such option or they did not sleep very well last night or they broke up with their girlfriend...
There are tons of people who file bug about ebuilds that provide step-by-step instructions what to do when emerge fails - like "this ebuild needs a configured kernel" or "USE=blah requires foo/bar emerged with USE=-bleh".
btrotter wrote: |
Does this figure give the Gentoo developers some form of perverse pleasure?
|
Definitely!!! |
|
Back to top |
|
|
btrotter n00b
Joined: 06 Oct 2005 Posts: 9
|
Posted: Sat Oct 08, 2005 5:08 pm Post subject: |
|
|
Hi,
A) If you think that building up knowledge is never a waste of time, then come and visit me for a few months and I'll teach you the Australian electrical wiring rules - I'm sure it'll help you one day.
B) The ebuild probably did try to warn me, but it was probably buried in thousands of lines of compiler output rather than being displayed when I did "emerge -pv world" or at the end where it says about configurations files that need updating. I can guarantee that, like many of the other posters here, I did not see this message.
C) It's entirely frustrating for users to continually suggest improvements and for those suggestions to be continually mis-read. The number of developers who have failed to see this as optional, and the number of developers who fail to consider how it would be implemented and then complain how hard it'd be to do something completely different is disappointing (but IMHO every single response from a developer so far has done this). Some of the developers may understood what I was saying and not replied, and I may even have been talking to a vocal minority - I have no way of knowing.
D) I'm still not complaining, and I'm still only trying to suggest an improvement. I admit it may have become difficult to tell due to frustration (see the last point), and I now realise that the same idea (or something similar) has probably been suggested hundreds of times already,and will probably be suggested hundreds of times in the future. This is why this post will hopefully be my last.
E) I realise that developer's time is a factor, yet no-one up until now has mentioned it as a reason why the idea couldn't be implemented (except for those who explained how hard it'd be to do something completely different).
F) If handled well, suggestions for improvements can (and often do) make a great project a little better, increase the number of developers, and/or increase community support. If these suggestions aren't handled well it can result in bad feeling for all concerned (see earlier user's posts for examples).
G) If a developer wrote "This idea or something like it has been suggested many times before and it's already been added to our 'Things to consider when there's time' list", then most of the unhappy posts would have been avoided. It wouldn't have even mattered if the idea actually went into a "Things we're sick of hearing" list or if it was sent it to "dev/null", no-one would have known (and earlier posters that decided to have nothing more to do with Gentoo may have left feeling like they weren't ignored, and may be telling everyone how great Gentoo is instead).
Cheers,
Brendan |
|
Back to top |
|
|
bakaohki Tux's lil' helper
Joined: 14 Jul 2005 Posts: 129 Location: Hungary
|
Posted: Sat Oct 08, 2005 5:49 pm Post subject: |
|
|
btrotter wrote: | Hi,
B) The ebuild probably did try to warn me, but it was probably buried in thousands of lines of compiler output rather than being displayed when I did "emerge -pv world" or at the end where it says about configurations files that need updating. I can guarantee that, like many of the other posters here, I did not see this message.
|
How about using portage logs? But actually this whole thread is a waste of time: it took me half an hour to fix the httpd.conf (which IS the usual way of configuring apache) and in case noone noticed Gentoo is not a commercial product you pay big bucks for (or the freeware little sister of some big distro). Hate fixing conf files after etc-updates? Then write a python script for the community and live happily ever after (read: until the next apache upgrade introduces one or two new variables and your unmaintained script breaks). |
|
Back to top |
|
|
Kloeri Retired Dev
Joined: 02 Sep 2002 Posts: 144
|
Posted: Sat Oct 08, 2005 5:57 pm Post subject: |
|
|
btrotter wrote: |
Paraphrasing my last post: "The optional option should be optional. The option should not break the emerge chain, but probably will because of unrelated bugs that aren't related (bugs that should probably be fixed sooner or later anyway)."
If people are smart enough to do "emerge -pv world" first (which IMHO isn't a problem), and if the developers are smart enough to implement this so that "emerge -pv world" also displays any warnings (which I'm honestly unsure about), then there wouldn't be any problem. |
I'm honestly not sure how this would work.. I guess you want portage to poke you when upgrading from an old style apache to new style?
The gets amazingly complicated as not all apache-2 ebuilds <-r30 is old style. And thinking about apache-1.x doesn't help either. There's also the case of how long we'd have to support this warning - what about further changes? Should portage just tell people that some attention is needed or do we need to tell people what's changed? That gets really complicated as some people updates every day, some updates once a month, some every 6 months, ..
I guess we could solve all this by just poking everybody when upgrading to new style ebuilds disregarding what's already installed. Of course that's just insane imo but would at least save us a lot of bugs working out all the old style / new style stuff and instead just annoying the hell out of everybody.
Call me a cynic but I don't see this idea working out without some serious consequences for everybody. We could put all the burden of this on the devs but that would just slow development to a crawl and make sure that most cool stuff would newer be implemented if it required any of this warning crap. As a dev I really don't want to spend more time holding peoples hands than I do on providing cool new software. |
|
Back to top |
|
|
96140 Retired Dev
Joined: 23 Jan 2005 Posts: 1324
|
Posted: Sat Oct 08, 2005 6:06 pm Post subject: |
|
|
Kloeri wrote: | As a dev I really don't want to spend more time holding peoples hands than I do on providing cool new software. |
And holding users' hands is what the Gentoo community is for, anyway. |
|
Back to top |
|
|
btrotter n00b
Joined: 06 Oct 2005 Posts: 9
|
Posted: Sun Oct 09, 2005 9:02 am Post subject: |
|
|
Hi,
Kloeri wrote: | I'm honestly not sure how this would work.. I guess you want portage to poke you when upgrading from an old style apache to new style? |
Yes, but more of a generic solution - a mechanism to allow portage to poke me when there's important upgrade information for any ebuild, where the "poking" is rather difficult to miss.
As an example (which ignores practicality concerns), allowing each ebuild to have associated "notifications" where (if the option has been enabled) each notification must be acknowledged before any ebuilds are updated. When someone does "emerge -pv world", "emerge world" or "emerge <package_name>" it'd check for any notifications (skipping those that have already been acknowledged) and stop before emerging anything at all if any notifications remain. Each notification would consist of a URL. It'd go something like this:
If some aren't acknowledged then the process is aborted, giving the user time to read the web page. Once all notifications are acknowledged, then all ebuilds are emerged (i.e. once portage begins installing packages it'd have no reason to stop).
I'd enumerate the notifications using a date format (e.g. "<package_name> <month><day><year>") and store a list of those that have been acknowledged in a file somewhere. Then I'd use a seperate file as part of the ebuild (e.g. "<package_name>.ebuild.notify") that contains the enumerated notification number/s and associated URL/s. That way, on the rare occasions where an ebuild may break compatibility, the developers would only need to add one line to the "<package_name>.ebuild.notify" file.
As for how long to keep the notifications, why not keep them for as long as the assoicated URL is valid? If the notifications are enumerated by date, then it'd be possible to ignore all notifications earlier than a certain date. For instance, if someone did a fresh install of apache2 today (rather than an upgrade), then any apache2 notifications that are earlier than the installation date could be ignored.
In the end, it would be impossible for a user that enables the "notifications" system to ever miss any notification. They wouldn't need to monitor mailing lists or anything, and wouldn't see notifications that aren't relevant to them (for e.g. if there's major changes to Gnome but they use KDE instead, then they needn't know).
Of course I fully understand that something like this may not be at all practical - I know very little of the internal workings of portage. However, I do assume that someone who has worked on the portage system before would be able to invent a better or more practical method of implementing similar functionality.
I agree something like this would take some time to design and implement, but once it's implemented it should reduce the time spent by developers, as the developers wouldn't need to try so hard to get announcements out there (or repond to forum topics like this one).
Cheers,
Brendan |
|
Back to top |
|
|
nixnut Bodhisattva
Joined: 09 Apr 2004 Posts: 10974 Location: the dutch mountains
|
Posted: Sun Oct 09, 2005 10:45 am Post subject: |
|
|
Kloeri wrote: | I'm honestly not sure how this would work.. I guess you want portage to poke you when upgrading from an old style apache to new style? |
How about an emerge option that outputs the ewarn messages from the pkg_postinst() of the ebuild if available?
These messages fly by when emerging packages and can easily be missed when emerging a list of packages. Having an option to display these warnings if available without emerging the packages would be nice. I'm not saying all ebuilds should have such messages, just that it would be a good idea to use that information when it is available without having to look at the ebuilds manually beforehand. _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered
talk is cheap. supply exceeds demand |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9523 Location: beyond the rim
|
Posted: Sun Oct 09, 2005 12:07 pm Post subject: |
|
|
nixnut wrote: | Kloeri wrote: | I'm honestly not sure how this would work.. I guess you want portage to poke you when upgrading from an old style apache to new style? |
How about an emerge option that outputs the ewarn messages from the pkg_postinst() of the ebuild if available?
These messages fly by when emerging packages and can easily be missed when emerging a list of packages. Having an option to display these warnings if available without emerging the packages would be nice. I'm not saying all ebuilds should have such messages, just that it would be a good idea to use that information when it is available without having to look at the ebuilds manually beforehand. |
Code: | ebuild foo.ebuild postinst |
It's not really feasable to only get the einfo/ewarn/eerror messages from it, if statements, functions calls, ... have to be considered.
EDIT: However, logging of einfo/ewarn/eerror is in portage-2.1 already and will almost certainly be backported to 2.0.x.
Last edited by Genone on Sun Oct 09, 2005 5:33 pm; edited 1 time in total |
|
Back to top |
|
|
96140 Retired Dev
Joined: 23 Jan 2005 Posts: 1324
|
Posted: Sun Oct 09, 2005 4:27 pm Post subject: |
|
|
nixnut wrote: | Kloeri wrote: | I'm honestly not sure how this would work.. I guess you want portage to poke you when upgrading from an old style apache to new style? |
How about an emerge option that outputs the ewarn messages from the pkg_postinst() of the ebuild if available?
These messages fly by when emerging packages and can easily be missed when emerging a list of packages. Having an option to display these warnings if available without emerging the packages would be nice. I'm not saying all ebuilds should have such messages, just that it would be a good idea to use that information when it is available without having to look at the ebuilds manually beforehand. |
Somebody actually has come up with an ebuild to do just that, or something similar anyway. It's not in portage, but I did read about it here on the forums.
It takes all the ewarn and einfo messages and outputs them to a file in the directory of your choice.
There's a similar package that does the same thing with the boot-up text you see scroll by when you turn on your computer . . . but that's as much as I remember about either of them. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9523 Location: beyond the rim
|
Posted: Sun Oct 09, 2005 5:34 pm Post subject: |
|
|
nightmorph wrote: | nixnut wrote: | Kloeri wrote: | I'm honestly not sure how this would work.. I guess you want portage to poke you when upgrading from an old style apache to new style? |
How about an emerge option that outputs the ewarn messages from the pkg_postinst() of the ebuild if available?
These messages fly by when emerging packages and can easily be missed when emerging a list of packages. Having an option to display these warnings if available without emerging the packages would be nice. I'm not saying all ebuilds should have such messages, just that it would be a good idea to use that information when it is available without having to look at the ebuilds manually beforehand. |
Somebody actually has come up with an ebuild to do just that, or something similar anyway. It's not in portage, but I did read about it here on the forums. |
If you're talking about enotice: No, that does just logging, which isn't exactly what was proposed here. |
|
Back to top |
|
|
nixnut Bodhisattva
Joined: 09 Apr 2004 Posts: 10974 Location: the dutch mountains
|
Posted: Sun Oct 09, 2005 5:55 pm Post subject: |
|
|
Genone wrote: | EDIT: However, logging of einfo/ewarn/eerror is in portage-2.1 already and will almost certainly be backported to 2.0.x. | Great, not quite there yet, but certainly a very nice improvement. Not too hard to generate some kind of message to an admin when a log is created. But still, getting warnings beforehand would be nice _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered
talk is cheap. supply exceeds demand |
|
Back to top |
|
|
Kloeri Retired Dev
Joined: 02 Sep 2002 Posts: 144
|
Posted: Mon Oct 10, 2005 2:43 pm Post subject: |
|
|
btrotter wrote: | Hi,
Kloeri wrote: | I'm honestly not sure how this would work.. I guess you want portage to poke you when upgrading from an old style apache to new style? |
Yes, but more of a generic solution - a mechanism to allow portage to poke me when there's important upgrade information for any ebuild, where the "poking" is rather difficult to miss.
As an example (which ignores practicality concerns), allowing each ebuild to have associated "notifications" where (if the option has been enabled) each notification must be acknowledged before any ebuilds are updated. When someone does "emerge -pv world", "emerge world" or "emerge <package_name>" it'd check for any notifications (skipping those that have already been acknowledged) and stop before emerging anything at all if any notifications remain. Each notification would consist of a URL. It'd go something like this: |
The point I was trying to make is more along the lines that (at least in the apache case) it's quite involved determining exactly which ebuilds are old-style and which are new-style. The first few -rX versions was old-style followed by some new-style, then again some old-style ebuilds, .. We kept it all separate by making sure all old-style ebuilds was marked stable and all new-style ebuilds was marked testing. If portage or the ebuilds should be clever about this and display a warning / require any kind of an acknowledgement only when needed this would require quite a bit of logic to solve and would probably lead to even more bugs. Leaving it to the admin seems like a much better idea in my opinion.
Logging of einfo, ewarn and eerror will hopefully solve most of this as the messages no longer just fly by. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9523 Location: beyond the rim
|
Posted: Mon Oct 10, 2005 3:04 pm Post subject: |
|
|
Kloeri wrote: | Logging of einfo, ewarn and eerror will hopefully solve most of this as the messages no longer just fly by. |
True, though I have to agree to some degree that it would be nice to have an option for "pre-install warnings" in some cases. Not sure how to implement such a thing though. |
|
Back to top |
|
|
j79zlr Apprentice
Joined: 05 Dec 2004 Posts: 235 Location: Chicago, IL
|
Posted: Mon Oct 10, 2005 10:33 pm Post subject: |
|
|
Whenever there is an upgrade to portage there is a large message that you can't miss, why not implement that for out-of-the norm changes to ebuilds, it doesn't break anything, or interfere with the normal process, just a big freaking message that you can't miss. I still think that /usr/portage/UPDATING is the simplest method. |
|
Back to top |
|
|
honeymak Guru
Joined: 30 Dec 2002 Posts: 537
|
Posted: Thu Oct 13, 2005 3:13 pm Post subject: |
|
|
maybe it's time to introduce a USE flag for users to choose between gentoo-style config files and the original pkg ones?
_________________ hackers - make sth real
academics - read sth said to be real |
|
Back to top |
|
|
w00dst0ck n00b
Joined: 26 Nov 2004 Posts: 24 Location: Toronto / Canada
|
Posted: Thu Oct 13, 2005 5:28 pm Post subject: |
|
|
Quote: | I still think that /usr/portage/UPDATING is the simplest method. |
I agree completely. Freebsd uses this method and it's a great help sometimes. _________________ -- w00dst0ck |
|
Back to top |
|
|
Fungos Bauux Tux's lil' helper
Joined: 09 Aug 2002 Posts: 98 Location: CWB
|
Posted: Thu Oct 13, 2005 11:04 pm Post subject: |
|
|
bad move... very bad move |
|
Back to top |
|
|
louman n00b
Joined: 02 Jan 2005 Posts: 31
|
Posted: Thu Oct 13, 2005 11:17 pm Post subject: |
|
|
geekmug wrote: | pjp wrote: | Though regarding informing the Gentoo community, I'd like to see something dedicated to announcing "major changes." |
What one person considers a "major update" is relative to what one does with their system. I have a laptop and a server running gentoo.. they use very different sets of packages. What would be ideal is a system for notifications based on what is installed on your system. I am sure many people would gladly sign up to a service in which portage notified a server about which packages they were interested in recieving major announcements about.
I'm not if I am being very clear about my idea, but I'm interested in it enough to make it happen just to avoid flamefests like this. |
I was just thinking of this. What if there was another element that could be optionally added to portage, so that every time you esync or what-not, relevent messages about the latest version of [xxxx] will printed to a file/emailed to you... something along those lines.
What's the closest thing like this that portage already has? |
|
Back to top |
|
|
llongi Retired Dev
Joined: 15 Apr 2004 Posts: 459 Location: Switzerland
|
Posted: Fri Oct 14, 2005 1:51 pm Post subject: |
|
|
louman wrote: | I was just thinking of this. What if there was another element that could be optionally added to portage, so that every time you esync or what-not, relevent messages about the latest version of [xxxx] will printed to a file/emailed to you... something along those lines.
What's the closest thing like this that portage already has? |
This already exists and was mentioned several times in this post: the "relevant news/changes" for each package are what composes the ChangeLog. So the "-l" option in emerge is the closest thing Portage has for this, it displays the relevant ChangeLog entries for that version of the package.
Best regards, CHTEKK. _________________ Best regards, Luca. |
|
Back to top |
|
|
sillielyd n00b
Joined: 10 Jul 2004 Posts: 1
|
Posted: Fri Oct 21, 2005 12:41 pm Post subject: [solved] Remove Apache2 |
|
|
How do I remove apache2? I'd rather install the older version. v2.0 sux
Last edited by sillielyd on Sat Oct 22, 2005 2:20 am; edited 1 time in total |
|
Back to top |
|
|
nixnut Bodhisattva
Joined: 09 Apr 2004 Posts: 10974 Location: the dutch mountains
|
Posted: Fri Oct 21, 2005 5:47 pm Post subject: Re: Remove Apache2 |
|
|
sillielyd wrote: | How do I remove apache2? I'd rather install the older version. v2.0 sux |
emerge -C apache && emerge =net-www/apache-1.3.33-r12 _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered
talk is cheap. supply exceeds demand |
|
Back to top |
|
|
twstd3bc Apprentice
Joined: 07 Feb 2003 Posts: 289 Location: Los Angeles, USA
|
Posted: Mon Dec 05, 2005 6:39 pm Post subject: Apache Alternative |
|
|
Is there a nice, small Apache alternative, for people who mostly serve static pages? /usr/portage/net-www doesn't seem to contain anything. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|