Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
What needs to be improved in Gentoo?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 10, 11, 12, 13  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  

What do you think about these suggestions?
I love them and I would like to help developing!
20%
 20%  [ 7 ]
I like them.
44%
 44%  [ 15 ]
They aren't important.
0%
 0%  [ 0 ]
I don't like them.
14%
 14%  [ 5 ]
They are stupid. Stop giving useless suggestions.
20%
 20%  [ 7 ]
Total Votes : 34

Author Message
Cinquero
Apprentice
Apprentice


Joined: 24 Jun 2004
Posts: 249

PostPosted: Fri Sep 01, 2006 8:11 pm    Post subject: Re: What needs to be improved in Gentoo? Reply with quote

sloppy wrote:
...


Maybe we should start sub-projects that use portage/emerge as a basis? (That way they could eventually even be distro-independent)

One such project could be some sort of an automatic problem solver: if emerge fails and someone has a solution, he puts the emerge output and the solution into a database. Others can then automatically try these possible solutions without any user intervention. One would -- of course -- need to classify the solution types: those who are not security-critical and those who are and must be acknowledged by the user. Example: problem with libtool -> re-emerge libtool package.

Another project would be to reliably detect unnecessary packages (fix for emerge --depclean).

At the essence of these proposals is that we should try to factor huge problems into different and widely independent parts. emerge/portage should do the basic stuff (stuff it already handles successfully and reliably, ie. emerging/unmerging single packages and determining dependencies), higher-level tools should do the more complicated stuff (revdep-rebuild is one such example).

A third project could be one that scans the executables and determines the linkage to resolve missing dependencies in ebuilds.

A fourth project could be one that manages use flags depending on more general and simpler directives, ie. "make everything work, but prefer ALSA as long as there is no disadvantage in doing so" (that would imply to use aoss for Java VMs without ALSA support etc.)
Back to top
View user's profile Send private message
mauricev
Apprentice
Apprentice


Joined: 22 Mar 2004
Posts: 193

PostPosted: Fri Sep 01, 2006 8:24 pm    Post subject: Reply with quote

Quote:
Make the need for a gcc-upgrade HOWTO go away.


Taken to its logical conclusion, make portage go away. Make Gentoo and Linux go away. The computer should update itself internally without the user ever having to open the hood so to speak. That's the day when computers are endowed with artificial intelligence (they won't really need updates anymore, anyway). That day will occur :idea: but for now, it's a long ways off. :( Right now, all we can ask for are just these baby steps. :)
Back to top
View user's profile Send private message
Cinquero
Apprentice
Apprentice


Joined: 24 Jun 2004
Posts: 249

PostPosted: Fri Sep 01, 2006 8:32 pm    Post subject: Reply with quote

mauricev wrote:
Taken to its logical conclusion, make portage go away. Make Gentoo and Linux go away.


Or just use a command distribution and execution utility and maintain basic Gentoo Linux installations as single nodes of a cluster... and let users manage only additional packages. I'm not using Gentoo Linux to mess around with toolchain upgrades. I use it because I can easily add additional packages and change existing ones in a consistent manner.
Back to top
View user's profile Send private message
Dralnu
Veteran
Veteran


Joined: 24 May 2006
Posts: 1919

PostPosted: Fri Sep 01, 2006 10:52 pm    Post subject: Re: What needs to be improved in Gentoo? Reply with quote

sloppy wrote:
Dralnu wrote:
Ok, we've all seen them. You know, the threads about how Gentoo sucks, and why it sucks, so I'm starting this. If you've got beef with a way something is done, or want to suggest how to improve something, post it. Lets keep it to constructive critism, I have no problem reporting people for trying to start flame wars or trolling. Thank you.


[Comment A] Make the need for a gcc-upgrade HOWTO go away. Whatever needs to be done, should be done when I emerge the new package.

Then make that true for every package. When I update a hundred packages, you can be sure I'm not reading everything that goes by on the screen. That means I miss stuff. That means stuff mysteriously breaks after I emerge updates and etc-update, because I'm not doing enough and DON'T KNOW that I'm not doing enough.

[Comment B]I like it when etc-update says "merging trivial changes." Make *all* /etc updates be trivial changes. ;-)

Bascially what the 3 things above mean, are that I am sometimes scared to update, or find it to be a lot of human (instead of computer) work. That sucks, even if it's my fault.

Make it so that xorg 7.1 isn't masked simply because some driver that I don't use isn't available. I got a Matrox G400MAX in order to *avoid* these (and many other related) problems. So *make* it so that the binary-driver-problem doesn't effect me.

Well, you asked. :-)


A) Personally, I wouldnt' care to emerge gcc-4.1.1/glibc-2.4 , and have it automatically switch to 4.1.1, then startup emerge -e system && emerge -e system && emerge -e world && emerge -e world right in the middle of the update ;)
I wouldn't want it to do that even afterwards without my intervention. Its a recipe for disaster

B) Thats an upstream issue in some cases, unless you want them to rename every package so you won't update further if the layout/syntax for a config file is changed ;)



No computer program can fix all human errors ;)
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
Back to top
View user's profile Send private message
Gooserider
Apprentice
Apprentice


Joined: 30 Dec 2005
Posts: 165
Location: Universe, Milky Way Galaxy, Solar System, Earth, North America, USA, MA, North Billerica

PostPosted: Sat Sep 02, 2006 8:55 pm    Post subject: Reply with quote

Sloppy, I agree with the sentiment of what you are saying, but....

etc-update changes CAN'T always be trivial :!: :cry: Sometimes they are being applied to files that YOU have edited to change the default behaviour on, or have other changes that NEED human evaluation to make sure they don't bork your box. Sometimes there are additions or changes to the default configs that need to be looked at by a person to make sure that a particular box will continue to act the way it's owner wants. The dev's aren't telepathic, they can't know what to set so that everybody's systems will work OK, especially since the answer will be different for different people. While etc-update could use more smarts, there also isn't a way to put enough AI smarts in it to solve all problems since that level of AI doesn't exist!

The problem is that etc-update is a really crappy tool which does a very poor job of judging which files need attention, does a poor job of showing what the differences are, and makes doing any changes other than just picking one version or the other gratuitously difficult. Cfg-update (which somebody in charge refuses to support (NIH syndrome??) as an official package, even though it works well) does a MUCH better job, and makes updates almost painless. It does a better job of evaluating and dealing with changes that don't need human intervention, so you have to look at fewer files. It uses a GUI like xxdiff or other three way merge tools so that you get the two files side by side with the differences flagged, and just have to click on which difference's version you want to use to create a merged version in a third window. If you need additional editing, it almost painlessly drops you into the editor of your choice, and so forth. If you do manage to mess things up, it also saves all the old versions so you can revert back as needed.

Much the same issue exists with upgrades and package installs in general. Overall the devs do an EXCELLENT job of doing packages that work on most systems. But every box is different, and it isn't possible to cover all the possible combinations of hardware and software even with more skill and talent than Gentoo has available. I do think there could be better tools / more automation to save out the important issue messages and present them after an upgrade. (maybe set a flag that tells portage to display a file after the last update or some such?) However there are ways to do this at present.

I also think that highly complex / high risk upgrades like upgrading gcc, changing X-versions, etc. should NOT be part of the standard emerge process. I want to be able to decide when / whether to do them or not, One can argue whether or not there should be more automation associated with the process, but I personally tend to think it doesn't hurt to do things manually so that one can do error intervention more easily if something goes wrong part way through the process.

Cinquero - I sort of like your idea of a problem solver database, but I'm not sure I'd want it to automatically apply solutions. There are two many cases where a given set of symptoms might have several causes, and the wrong solution would cause even more problems. Thus it would probably be a good idea to do further diagnostics to confirm the exact cause of a given problem that might only sound like the one described in the database.

The problem is that, especially for non-experts, it can be hard to know what the potential causes are or how to diagnose them, etc. A problem solving database would be good in that it at least can give the user a starting point for investigating.

There are severe security and privacy implications for automatic diagnostics - it isn't to bad if a program like portage that is already "phoning home" to request a package to send a second message saying "I just exited with <THIS> error, what happenned?" but an accurate diagnosis would probably require much more information than just the failing error message. There is the security question of opening things up to let a diagnostic tool look at files that might you might not normally want exposed, without also leaving a malware hole. Furthermore, for the paranoids among us, how much information about what is on your system, how it's configured, etc. do you want to expose to a 3rd party. OTOH, it would be nice if when a problem happened portage would pop up a window or something saying "These are possible causes and solutions of the failure that just occurred." with either a list of things and solutions, or a bunch of pointers to the same. (probably the latter to save resources).

This would let the user investigate privately, and apply the needed solution without the security risks an automatic diagnostic tool would involve. It would avoid some of the potential issues raised by automatically appying a wrong solution and borking a box - There is a big blame difference between a Gentoo program automagically borking a box and a user doing the same thing because he blindly followed a process w/o properly diagnosing the problem... Another advantage is that it would allow a much wider range of complexity to be described in both diagnosing a problem and with solving it.

Gooserider
_________________
Box 1: P2 Celeron 400, 320mb RAM, 80GB HD, Cirrus Logic 4614/22/24 sound card, ATI 3D RAGE PRO AGP 1X/2X (sound & video onboard)
Box 2: AMD Athlon 2500+ 512mb RAM, 80GB HD, Gigabyte K7 Triton (Nvidia) mobo, GeForce2 video
Back to top
View user's profile Send private message
Cinquero
Apprentice
Apprentice


Joined: 24 Jun 2004
Posts: 249

PostPosted: Sat Sep 02, 2006 11:00 pm    Post subject: Reply with quote

@Gooserider: I agree with both of your concerns (reliability and privacy). The former is solved by my proposed classification of solution _tries_: ones that could mess up your system and ones that don't -- like just reemerging specific packages. The privacy issue can easily be solved by not sending any information automatically. I don't see any need for it. If there is a problem with a specific ebuild, the problem handling tool could just retrieve ALL solutions from the server and evaluate them locally. I had this idea of a FAQ script that automatically determines the relevant questions. That is basically something very similar: instead of just filing bug reports and solutions, why not enter it into some database that can be used by a program? I know that does not work everywhere, but noone says he wants to do THAT. Just remove the most basic and most frequent problems -- which could also take quite a load from the bug reports maintaining people.

Regarding the issue with the /etc updates: define a basic set of configuration options, then store that in some sort of format- and app-independent file (like we already almost do in /etc/conf.d -- except that giving command line arguments is not what one may call app-independent). Then mark those ebuilds that can configure themselves using that information as "auto-configurable". These will construct the correct /etc files during build time and automatically overwrite the previous (automatically generated) ones without user-intervention, and portage would be able to restart updated services instantly.

One could then go one step further and manage those Gentoo systems, that have auto-configuration enabled, centrally -- if the user likes to. That means that (at least at first) the user would be reponsible only for addtional, non-critical packages (which are not marked as auto-configurable). The critical packages would send error reports back to the central site -- either automatically or after the user has reviewed the report. The group of admins at the central site could then in most cases rapidly detect any serious problems and fix it. The remote administration commands could be verified by the user first, if he wishes to. He could, of course, also tell the remote admin daemon to require at least N valid gpg signatures from a core group of trusted admins... (think, for example, of MySQL upgrades. There are various issues with the charset settings etc., and it would be really nice if such things would work automagically and reliably. Upgrade scripts would try the upgrade on "testing" machines (declared by the users, some self-declared victims), and would use checks to see if the data has been properly migrated. If not, the emerge operation of the new MySQL backend would be undone and everything be put back in place, resulting in probably many error reports that could provide quite useful information to sort out problems quickly)

The point with AI -- as I see it -- is that AI today mostly only works if you put a considerable amount of knowledge into it. That's what I'm talking about. Put the knowledge into the ebuilds or some separate script archive such that (at least) the (simple) configuration files may be created correctly. A package maintaining script (which could use apt, rpm, yum, emerge etc.) would then be able to choose appropriate packages depending on the configuration. Such a solution would be very similar to the other distros (at least when looking at it from the user's side), but open-source/Linux is about choice. The usual Gentoo feeling would not be lost as the user/dev could still disable all of that -- or, what is probably better in many cases, just acknowledge a list of proposed commands and/or solutions. That way he would still know all details of his system and what is going on in it, but would not have to fiddle around that much.

I'd really like to start such a thing, but I won't do it if there isn't serious support coming from others. For example, we need at least a bunch of people willing to check and sign the remote administration commands/scripts.

EDIT:

BTW: I just discovered that kernel.org does provide a GPG key but does not provide a safe way to download it, ie. SSL using a Cert from a well-known CA. And what about portage tree security? See https://forums.gentoo.org/viewtopic-p-3551487.html . The situation is a shame. The debian people take that serious. And the firefox/mozilla people introduced SSL for downloads just a few months ago (I complained there, too). RPM checks signatures, too.

EDIT 2:

YAFP (yet another feature proposal): add a '--machine-readable' option to emerge to produce easily parsable and (that's even more important) standardized (ie. guaranteed to never change) output. If you need another format of meachine readable format, it should be introduced by adding versioned arguments, ie. '--machine-readable-2'. It's not that the current output is not machine-readable, but it would be nice to have it of a form like "<list entry number> category package version(range) <requirements> <is dependency for>". That way it would be much easier to create internal program structures because the pointers are already there: requirements and "dependency for" ("backlinks") entries are comma-separated lists of "list entry numbers" which go from 1 to N. The version range (list) would be the intersection of requirements imposed by all included ebuilds.

EDIT 3:

/etc/pam.d/login should not strictly require the selinux module. pam's selinux support was broken lately and therefore one should be able to login also if no selinux module is present. Can't pam use the selinux module if it is there and ignore it if not? (looks like one just has to replace "required" with "optional" in the config file)
Back to top
View user's profile Send private message
derverstand
Guru
Guru


Joined: 15 Dec 2005
Posts: 511
Location: /dev/null

PostPosted: Tue Sep 19, 2006 5:42 pm    Post subject: Reply with quote

I'm using the gentoo distro for more than two years now. It seems to me that the idea of portage is quite genious. But the release management is really amateurish. I don't want to go into detail, but: Too many packages are marked stable too early.

(1) Why are there philosophical hard masked packages, which are proven to work better than the "stable" ones (i.e. Xorg-6.9)?
(2) How is it possible for example, that after a gcc update my fortran g77 vanished?
(3) Why is a gentoo mirror not complete? There are external refenrences to third parties.

Let me point out again, that I don't want to start a discussion about the above examples! It is a fact, that most of all serious updates simply go wrong (Yes, I read the man pages; yes I know how to fix the problems).

My point is pretty simple: Why don't one makes different releases, like debian? A stable ancient one, a bleeding edge one (this would be the actual stable version)? At the moment I'm doing exactly this for myself on my own rsync-server. At first some testing in vmware, then marking marking some packages as stable.

Best regards!
Back to top
View user's profile Send private message
Dralnu
Veteran
Veteran


Joined: 24 May 2006
Posts: 1919

PostPosted: Tue Sep 19, 2006 6:20 pm    Post subject: Reply with quote

There is a file with the reasoning to the hard masked packaged. Some are there because they are hard to maintain. Some are there because they are insecure. Some are there because they are not ready for a release, but are in beta.
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
Back to top
View user's profile Send private message
derverstand
Guru
Guru


Joined: 15 Dec 2005
Posts: 511
Location: /dev/null

PostPosted: Tue Sep 19, 2006 6:27 pm    Post subject: Reply with quote

As I wrote, I don't want to start a discussion about this: Here the summarized version of what could be improved, to make gentoo useable:

(1) Build complete mirrors (consistency)! Or at least provide a (better version of my) script to download everything for an own mirror.
(2) Create two kinds of releases: STABLE / INSTABLE where instable would be the actually stable marked distribution - there are too many inconsistencies in the "INSTABLE" version for professional using gentoo. (consistency again).
(3) Put a function in emerge, that displays the changelog of the package, so one can comprehend whats to be updated.

Best regards.
Back to top
View user's profile Send private message
Cinquero
Apprentice
Apprentice


Joined: 24 Jun 2004
Posts: 249

PostPosted: Tue Sep 19, 2006 6:49 pm    Post subject: Reply with quote

derverstand wrote:
As I wrote, I don't want to start a discussion about this: Here the summarized version of what could be improved, to make gentoo useable:
...


I think you are misunderstanding the nature of Gentoo. If you want Debian, then use Debian and not Gentoo. Most of us probably use Gentoo partly because there is no global stable/unstable thing. We should rather think about a way to improve the package QA -- like running build test daemons on some users' computers (~ automated arch testers), but not on the real root, but on a chrooted copy of it. Problems due to the sheer diversity of the ebuild/portage system could then possibly be much faster and much more reliably detected -- leading to the possibility of testing ebuilds in a diverse environment before putting them into the stable branch.

----

NEW FEATURE: PARALLEL_FETCH

Enable parallel fetch support for portage. Use the mirrors in parallel, not in sequential order. it should be easy to split files into chunks if using curl. I often have problems with servers being down or not satisfying the speed of my DSL connection. If a mirror server connection gets idle, let it download another connection's task/data block to avoid delays due to slow servers completely. Maybe, that even has the effect of a client-side load-balancing.


Last edited by Cinquero on Fri Sep 22, 2006 12:16 am; edited 3 times in total
Back to top
View user's profile Send private message
derverstand
Guru
Guru


Joined: 15 Dec 2005
Posts: 511
Location: /dev/null

PostPosted: Tue Sep 19, 2006 6:56 pm    Post subject: Reply with quote

I probably understand the nature of gentoo: the portage. This doesn't exclude, that there are different portage versions one can sync with. This kind of conversation is chat-alike: Not pragmatic / constructive...
Gentoo provides a comfortable way to compile a linux system on your own. The portage itself is a very good idea. But the ebuilds should attended more. In fact gentoo consists only of the portage / ebuilds... Everything else is secondary...
Back to top
View user's profile Send private message
Dralnu
Veteran
Veteran


Joined: 24 May 2006
Posts: 1919

PostPosted: Tue Sep 19, 2006 7:30 pm    Post subject: Reply with quote

I wasn't discussing. I was stating.


And if you've found a mirror that isn't complete, make sure its offical, then report it.
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
Back to top
View user's profile Send private message
kharan5876
n00b
n00b


Joined: 15 Jan 2006
Posts: 66

PostPosted: Tue Sep 19, 2006 8:19 pm    Post subject: Reply with quote

Didnt read the others but the only real problems ive come across in gentoo are broken/buggy ebuilds and lack of ebuilds for certain programs.

Also package.cflags would be cool
Back to top
View user's profile Send private message
derverstand
Guru
Guru


Joined: 15 Dec 2005
Posts: 511
Location: /dev/null

PostPosted: Sat Sep 23, 2006 9:16 pm    Post subject: Reply with quote

Hi,

What about a non-sanbox-branch of Gentoo for people who want to USE linux and not play around with colored output and higher version numbers: https://forums.gentoo.org/viewtopic-t-501166-highlight-.html

Best regards.
Back to top
View user's profile Send private message
beandog
Bodhisattva
Bodhisattva


Joined: 04 May 2003
Posts: 2072
Location: /usa/utah

PostPosted: Sat Sep 23, 2006 11:54 pm    Post subject: Reply with quote

derverstand wrote:
I'm using the gentoo distro for more than two years now. It seems to me that the idea of portage is quite genious. But the release management is really amateurish. I don't want to go into detail, but: Too many packages are marked stable too early.


If you are upset with the way packages are marked stable on your architecture, then I highly encourage you to become an arch tester to have a voice when stablity requests are filed.


derverstand wrote:
(1) Why are there philosophical hard masked packages, which are proven to work better than the "stable" ones (i.e. Xorg-6.9)?
(2) How is it possible for example, that after a gcc update my fortran g77 vanished?
(3) Why is a gentoo mirror not complete? There are external refenrences to third parties.

Let me point out again, that I don't want to start a discussion about the above examples! It is a fact, that most of all serious updates simply go wrong (Yes, I read the man pages; yes I know how to fix the problems).


A lot of people tend to generalize the problems Gentoo has, but in reality it's just a few irksome things that have gone wrong for them. I'd venture to say that is the norm and not the exception. The great thing about Gentoo is it gives you the flexibility and tools to play around and make minor changes and fixes without having to do a complete reinstall or upgrade to a whole new release.

derverstand wrote:
My point is pretty simple: Why don't one makes different releases, like debian? A stable ancient one, a bleeding edge one (this would be the actual stable version)? At the moment I'm doing exactly this for myself on my own rsync-server. At first some testing in vmware, then marking marking some packages as stable.


For the same reason we don't do things like Fedora, Red Hat, Mandrake and Slackware. They are not us and we are not them.
_________________
If it ain't broke, tweak it. dvds | blurays | blog | wiki
Back to top
View user's profile Send private message
Drysh
Apprentice
Apprentice


Joined: 06 Apr 2005
Posts: 203
Location: São Paulo, Brazil

PostPosted: Sat Sep 23, 2006 11:57 pm    Post subject: Reply with quote

I would like to see two new options for emerge:

--ask-each-package (-aa): After creating the list of packages to be emerged, ask for confirmation on each emerge. That way you could manualy exclude dangerous updates.

--messages-last (-vv): Save the messages for after the emerge, all of them together. Or (-vv) print them while emerging and again after it.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Sep 24, 2006 1:10 am    Post subject: Reply with quote

mauricev wrote:
Quote:
Make the need for a gcc-upgrade HOWTO go away.


Taken to its logical conclusion, make portage go away. Make Gentoo and Linux go away. The computer should update itself internally without the user ever having to open the hood so to speak. That's the day when computers are endowed with artificial intelligence (they won't really need updates anymore, anyway). That day will occur :idea: but for now, it's a long ways off. :( Right now, all we can ask for are just these baby steps. :)


What steps would it take to deliver that?
Back to top
View user's profile Send private message
Cinquero
Apprentice
Apprentice


Joined: 24 Jun 2004
Posts: 249

PostPosted: Sun Sep 24, 2006 2:25 am    Post subject: Reply with quote

steveL wrote:
What steps would it take to deliver that?

Install Windows XP. It has an auto update feature. But, unfortunately, also an expiry date. :-)
Back to top
View user's profile Send private message
phatscum
n00b
n00b


Joined: 20 Mar 2006
Posts: 34
Location: Down the sewers

PostPosted: Sun Sep 24, 2006 3:56 am    Post subject: Reply with quote

Drysh wrote:
I would like to see two new options for emerge:

--ask-each-package (-aa): After creating the list of packages to be emerged, ask for confirmation on each emerge. That way you could manualy exclude dangerous updates.

--messages-last (-vv): Save the messages for after the emerge, all of them together. Or (-vv) print them while emerging and again after it.

^ What he said!
_________________
Computer games don't affect kids, I mean, if pacman affected us as kids we'd all run around in a darkened room munching pills and listening to repetitive music.
Back to top
View user's profile Send private message
Dralnu
Veteran
Veteran


Joined: 24 May 2006
Posts: 1919

PostPosted: Sun Sep 24, 2006 4:04 am    Post subject: Reply with quote

Drysh wrote:
--messages-last (-vv): Save the messages for after the emerge, all of them together. Or (-vv) print them while emerging and again after it.


This has been covered before. The devs seem to refuse to, or are just too lazy to do it. There is an ELOG in the make.conf.example you could look at, but the default doesn't work for me, and I don't feel like fighting with it just to get something to spit out messages to the root account (it cann't email to multiple users), and just so you know, that feature seems to be done.
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Sep 24, 2006 4:50 am    Post subject: Reply with quote

Cinquero wrote:

The point with AI -- as I see it -- is that AI today mostly only works if you put a considerable amount of knowledge into it. That's what I'm talking about. Put the knowledge into the ebuilds or some separate script archive such that (at least) the (simple) configuration files may be created correctly.

Expert systems definitely work on knowledge bases, but there is more interesting stuff to AI! Check out Prolog for one.
Although I agree that simple config files should be automatic, ATM you get good defaults.
A generic option wizard for *any* config script would be cool.

Another personal bugbear would be to stop putting /usr binaries' config files in /etc. That's what /usr/etc is for!

Quote:
A package maintaining script (which could use apt, rpm, yum, emerge etc.) would then be able to choose appropriate packages depending on the configuration. Such a solution would be very similar to the other distros (at least when looking at it from the user's side), but open-source/Linux is about choice. The usual Gentoo feeling would not be lost as the user/dev could still disable all of that -- or, what is probably better in many cases, just acknowledge a list of proposed commands and/or solutions. That way he would still know all details of his system and what is going on in it, but would not have to fiddle around that much.


What do you mean by choice of appropriate packages wrt to config files?
Back to top
View user's profile Send private message
43r05p4c3
n00b
n00b


Joined: 29 May 2006
Posts: 17
Location: Ontario, Canada

PostPosted: Sun Sep 24, 2006 6:30 am    Post subject: Reply with quote

K, I'm sure this has been said a million times, a million ways in this thread, but with a computer that connects to the internet for updates, the problem has so far been singular:

UPDATES!!!

I say this since everything that could give me problems... has. First (this may have been a server problem actually), emerge --sync didn't work until after i'd run the web-sync option. Next, a complete update was blocked by the old version of X. Then I couldn't update X because sandbox was out of date. So far the first was probably server related, and the rest should have been managed by portage in my opinion (although I might accept modular X as being too different and complex to easily update by portage). But the real issue is what followed next.

Sandbox wouldn't update... because SANDBOX WASN'T UP TO DATE!!!!

That's a load of BS. Maybe I'm bitter cause I've spent over a week getting this thng up to date (spending long enough that after finishing a re-update will be difficult), but frankly I think protage should be expected to be able to update something that's more than a couple versions out of date. Isn't that the purpose?

At the least, if I run a: #emerge --update --deep --newuse world
Shouldn't the assumption be that my system is probably significantly out of date?

As it stands, I updated sandbox. updated X... but haven't tested it, and tried to emerge --update --deep world. but now some program is being blocked by it's old libraries... that aren't being updated.

Ok, I'm not a programmer. I can't handle too much past the most BASIC of programs. But here's a suggestion on where to start: keep the date of the last portage tree from which updates are simple. Then, if the current version is older than the required date, it simply gets unmerged, then the newest version gets remerged. if you want, make a new option, so people will run #emerge --deep --update --old --newuse world. That way, the computer knows that this is an old version of Gentoo and will have troubles updating.

Well, hopefully you'll make updating easier at some point, but either way, to you developers, keep up the phenominal work. There aren't enough of you,

Steve
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Sep 24, 2006 10:18 am    Post subject: Reply with quote

I've had similar probs with sandbox in the past. Real pain, and upgrading a server around the time of 1.4; ended up having to start over on a different box.

This discussion is heading in a similar direction.
Back to top
View user's profile Send private message
Cinquero
Apprentice
Apprentice


Joined: 24 Jun 2004
Posts: 249

PostPosted: Sun Sep 24, 2006 1:38 pm    Post subject: Reply with quote

steveL wrote:
What do you mean by choice of appropriate packages wrt to config files?


For example, one web server supports one feature, another one supports another feature. The features listed in a generic config file could be used to select the appropriate web server.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Sep 27, 2006 9:49 am    Post subject: Reply with quote

Cinquero wrote:
steveL wrote:
What do you mean by choice of appropriate packages wrt to config files?

For example, one web server supports one feature, another one supports another feature. The features listed in a generic config file could be used to select the appropriate web server.


OK, I get you, although I don't think that's majorly useful- maybe there's a better example tho.

One thing I'd like to see is per-package overrides/ appends on stuff like CFLAGS (eg if I want to debug a package, I'd set an override to take away -fomit-frame-pointer and add -g) and LDFLAGS (eg add Wl,z,now for QA notices such as xorg is `setXid, dyn linked, and using lazy bindings').

A bigger change would be the one to have an unstable (current testing), testing and stable set. It seems from what others have said that testing can be too bleeding edge and stable can significantly lag behind upstream.

[contentious]I'd also like to see packages like samba with the option of only compiling the client, in line with the philosophy of only having what you need. I understand this can be done by unpack and configuring, I'd just like it automated.

Further, I don't think it helps us when a standard upgrade breaks a system.[/contentious]
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3 ... 10, 11, 12, 13  Next
Page 11 of 13

 
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