FS#13338 - What happened to vanilla?
Attached to Project:
Arch Linux
Opened by kongokris 2 (nut543) - Tuesday, 17 February 2009, 14:12 GMT
Last edited by Aaron Griffin (phrakture) - Tuesday, 17 February 2009, 19:00 GMT
Opened by kongokris 2 (nut543) - Tuesday, 17 February 2009, 14:12 GMT
Last edited by Aaron Griffin (phrakture) - Tuesday, 17 February 2009, 19:00 GMT
|
Details
I do no think that it is a high awareness of what
constitutes "vanilla" packages, so not knowing where or how
I could implement this higer awareness, whether it is
posting it in the wiki or whatever, i'm posting it here as a
"General Gripe"
The reason i say it is not a high awareness about what is vanilla i have two examples: 1: http://bbs.archlinux.org/viewtopic.php?id=65506 Here we see careless attitude about whether or not to add a configure option by a dev. In example 2. we see how adding a configure option to a package creates a bug: 2: elinks. First try compiling it without anything but the standard ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc and then try the abs one. If you visit any norwegian website you will get øæå errors. Also see: elinks-git in aur i suppose.. My point being that adding configure options that is not "standard" for upstream is going to cause more errors for the sheer fact it isn't tested as much. This is also an aspect of "vanilla" packaging; it doesn't /just/ hold for patches. This is just the example i have at hand, I remember iv'e had issues with other packages in the past aswell(that just needed to be stripped of some configure option) and that is really what prompts this. If someone points me in the right direction of what to do this that would implement this higher awareness, i'd be happy to do it. |
This task depends upon
Closed by Aaron Griffin (phrakture)
Tuesday, 17 February 2009, 19:00 GMT
Reason for closing: None
Additional comments about closing: See comments. Discussion is over
Tuesday, 17 February 2009, 19:00 GMT
Reason for closing: None
Additional comments about closing: See comments. Discussion is over
Short answer: Vanilla died the moment the bugtracker got a Feature Request Task Type. It might never have really existed even before that.
Long answer: I see nothing wrong with Allan's behaviour. Quite the contrary.
People want features. If you build elinks in a clean chroot without any --enable options it will be the same as links. No javascript, no lua, no nothing. People who use elinks dont want that. Maybe they dont need ALL the available features, but they certainly dont want the browser to be featureless.
If someone makes a request for a feature to be added, that adds little, or no overhead or even adds a feature most people want, it will probably be added. Its as simple as that.
Vanilla from my point of view concernes only patches and features not in the package. Its not about features that are part of the package.
eg is an e2fsprogs with --enable-elf-shlibs or --enable-fsck not "vanilla" because its not enabled by default?
Vanilla the way you mean it is an illusion when it comes to binary packages. Even Slackware isnt vanilla like that. CRUX might be to some extend, but its a source based distribution for the most part.
As far as the issues you remember having, that the primary purpose of the bug tracker. To let the developers know about them and solve them.
1) If a configure option cause errors, it is an upstream bug, it is good to detect it and to report it upstream
2) If you want packages with correct dependencies, it is usually much safer to disable and enable explicitly dependencies, to limit the effect of the environment as much as possible. Of course the ideal is to use a clean chroot, but many developers don't even do that, so some safety never hurts anyway.
"This is also an aspect of "vanilla" packaging; it doesn't /just/ hold for patches."
There is the ideal world, and there is the reality. Crappy build systems, stupid defaults, lazy and inactive upstream, etc..
In short, if a package is broken due to configure flags, file a bug for that package. Bugreports like this are useless because they don't point at a real bug. The only example you give is elinks, which can be fixed.
Elinks built, to take that as an example(but in reality it applies generally), just with --prefix=/usr, DO have javascript support. It doesn't compile in Lua support. I don't want that and i imagine most people do not take the time to configure webpage display with lua, so i imagine we got most bases covered with the default setup here. No need to add more flags.
"Since when is USING a configure option that is supplied BY upstream not "vanilla"?"
Ok your right, and i used that word erroneously in lack of a better one. However i'm making the point that if we try to stay with the ./configure line(or any buildsystem line) that the author recommends OR is the default one then we would get less problems.
I'd guess a lot of problems are due to Devs and TU's not using chroots though so I'll make a feature suggestion that would mandate devs use of a chroot or a mechnanism that would yield the equivalent result.