Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Gentoo Apache2 Config Change Idiocy
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 8, 9, 10, 11  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
btrotter
n00b
n00b


Joined: 06 Oct 2005
Posts: 9

PostPosted: Sat Oct 08, 2005 2:11 pm    Post subject: Reply with quote

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
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Sat Oct 08, 2005 3:10 pm    Post subject: Reply with quote

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. :twisted:
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.? :roll:
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
View user's profile Send private message
fuji
Tux's lil' helper
Tux's lil' helper


Joined: 26 Apr 2002
Posts: 111

PostPosted: Sat Oct 08, 2005 3:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
j-m
Retired Dev
Retired Dev


Joined: 31 Oct 2004
Posts: 975

PostPosted: Sat Oct 08, 2005 3:54 pm    Post subject: Reply with quote

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!!! :twisted: :twisted: :twisted:
Back to top
View user's profile Send private message
btrotter
n00b
n00b


Joined: 06 Oct 2005
Posts: 9

PostPosted: Sat Oct 08, 2005 5:08 pm    Post subject: Reply with quote

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
View user's profile Send private message
bakaohki
Tux's lil' helper
Tux's lil' helper


Joined: 14 Jul 2005
Posts: 129
Location: Hungary

PostPosted: Sat Oct 08, 2005 5:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
Kloeri
Retired Dev
Retired Dev


Joined: 02 Sep 2002
Posts: 144

PostPosted: Sat Oct 08, 2005 5:57 pm    Post subject: Reply with quote

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
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Sat Oct 08, 2005 6:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
btrotter
n00b
n00b


Joined: 06 Oct 2005
Posts: 9

PostPosted: Sun Oct 09, 2005 9:02 am    Post subject: Reply with quote

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:

Quote:
foo # emerge world
Calculating world dependencies ...done!
Checking for notifications ...done!

Package 'Apache2' has one notification set:
URL: http://www.gentoo.org/doc/en/apache-upgrading.xml

Acknowledge this notification (Y or N):


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
View user's profile Send private message
nixnut
Administrator
Administrator


Joined: 09 Apr 2004
Posts: 10973
Location: the dutch mountains

PostPosted: Sun Oct 09, 2005 10:45 am    Post subject: Reply with quote

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
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 8995
Location: beyond the rim

PostPosted: Sun Oct 09, 2005 12:07 pm    Post subject: Reply with quote

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
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Sun Oct 09, 2005 4:27 pm    Post subject: Reply with quote

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
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 8995
Location: beyond the rim

PostPosted: Sun Oct 09, 2005 5:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
nixnut
Administrator
Administrator


Joined: 09 Apr 2004
Posts: 10973
Location: the dutch mountains

PostPosted: Sun Oct 09, 2005 5:55 pm    Post subject: Reply with quote

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 :wink:
_________________
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
View user's profile Send private message
Kloeri
Retired Dev
Retired Dev


Joined: 02 Sep 2002
Posts: 144

PostPosted: Mon Oct 10, 2005 2:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 8995
Location: beyond the rim

PostPosted: Mon Oct 10, 2005 3:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
j79zlr
Apprentice
Apprentice


Joined: 05 Dec 2004
Posts: 235
Location: Chicago, IL

PostPosted: Mon Oct 10, 2005 10:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
honeymak
Guru
Guru


Joined: 30 Dec 2002
Posts: 456

PostPosted: Thu Oct 13, 2005 3:13 pm    Post subject: Reply with quote

maybe it's time to introduce a USE flag for users to choose between gentoo-style config files and the original pkg ones?
:roll:
_________________
hackers - make sth real
academics - read sth said to be real
http://facebook.com/honey.mak
Back to top
View user's profile Send private message
w00dst0ck
n00b
n00b


Joined: 26 Nov 2004
Posts: 24
Location: Toronto / Canada

PostPosted: Thu Oct 13, 2005 5:28 pm    Post subject: Reply with quote

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
View user's profile Send private message
Fungos Bauux
Tux's lil' helper
Tux's lil' helper


Joined: 09 Aug 2002
Posts: 98
Location: CWB

PostPosted: Thu Oct 13, 2005 11:04 pm    Post subject: Reply with quote

bad move... very bad move :(
Back to top
View user's profile Send private message
louman
n00b
n00b


Joined: 02 Jan 2005
Posts: 31

PostPosted: Thu Oct 13, 2005 11:17 pm    Post subject: Reply with quote

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
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Fri Oct 14, 2005 1:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
sillielyd
n00b
n00b


Joined: 10 Jul 2004
Posts: 1

PostPosted: Fri Oct 21, 2005 12:41 pm    Post subject: [solved] Remove Apache2 Reply with quote

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
View user's profile Send private message
nixnut
Administrator
Administrator


Joined: 09 Apr 2004
Posts: 10973
Location: the dutch mountains

PostPosted: Fri Oct 21, 2005 5:47 pm    Post subject: Re: Remove Apache2 Reply with quote

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
View user's profile Send private message
twstd3bc
Apprentice
Apprentice


Joined: 07 Feb 2003
Posts: 289
Location: Los Angeles, USA

PostPosted: Mon Dec 05, 2005 6:39 pm    Post subject: Apache Alternative Reply with quote

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
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3 ... 8, 9, 10, 11  Next
Page 9 of 11

 
Jump to:  
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