Re: [arch-general] A suggestion for the devs regarding rebuilds
Allan McRae wrote:
With every big rebuilds we get new breakage stories. It seems like it's the norm nowadays rather than the exception.
I am wondering if it's really only the users that are to blame.. or if Arch is also to blame. Or if Arch was supposed to be an elitist distribution and is victim of its success.
I think the answer to that is in the question: What did we do different previously that resulted in far less of these issues?
My impression is that nothing has particularly change in terms of how rebuilds are handled. If anything, the whole process has become a lot more streamlined and cases of missing a package rebuild are now almost non-existent.
So the cause must be... A change in user-base? Maybe just an increase in user-base resulting in more people who think Arch should be done their way and not the Arch way?
Well, I think this viewpoint is too elitist... I am not sure that you should blame users who just read http://wiki.archlinux.org/index.php/Font_Configuration#LCD_filter_patched_pa... and who don't even know that cairo is a dependency of gtk2. (Come on, do you know well every installed library on your system?) And with broken cairo the user just gets "fav_gtk_app: error while loading shared libraries...", so it requires a little bit sophisticated bug-hunting. I just mention the "-Sy system_breaker_package" issue again, where sodepends or libpng14 could help. I know that these system breakages require some user fault too, but I think the main purpose of pacman (should be) to not allow break our system. If I accepted your standpoint as a solution, I would suggest to not use %CONFLICTS% array or versioned dependencies ;-) (Because "elite" users should know that foo conflicts with bar, and all his packages [dependencies] should be always up-to-date...) Bye
On Tue, Feb 09, 2010 at 01:20:15AM +0100, Nagy Gabor wrote:
Allan McRae wrote:
So the cause must be... A change in user-base? Maybe just an increase in user-base resulting in more people who think Arch should be done their way and not the Arch way?
Well, I think this viewpoint is too elitist... I am not sure that you should blame users who just read http://wiki.archlinux.org/index.php/Font_Configuration#LCD_filter_patched_pa... and who don't even know that cairo is a dependency of gtk2. (Come on, do you know well every installed library on your system?) And with broken cairo the user just gets "fav_gtk_app: error while loading shared libraries...", so it requires a little bit sophisticated bug-hunting.
Yes, but it's the duty of the AUR-package maintainer to bump the pkgrel version to indicate taht this package (in this case cairo-lcd) needs to be rebuild. And on the other hand it's the user's "duty" to take care of his own built packages, ie to actually rebuild the package. I see nothing elitist therein. It's just a simple usage procedure. --
On 09/02/10 10:20, Nagy Gabor wrote:
If I accepted your standpoint as a solution, I would suggest to not use %CONFLICTS% array or versioned dependencies;-)
I actually do suggest not to use versioned dependencies... that way when someone did a "pacman -Sy breakingpkg", it would not pull in the new library version and on the new package would be "broken" because of a missing library. Versioned dependencies are a broken hack. Allan
On Mon, Feb 8, 2010 at 10:46 PM, Allan McRae <allan@archlinux.org> wrote:
I actually do suggest not to use versioned dependencies... that way when someone did a "pacman -Sy breakingpkg", it would not pull in the new library version and on the new package would be "broken" because of a missing library. Versioned dependencies are a broken hack.
Just one crazy idea that crossed my mind... It would be very nice if we could mark some files in a package so that when updating the package, they would not be removed and, instead, would be added to the list of files belonging to that package. Let's say: in libpng, /usr/lib/libpng.so.1.2 will be marked as such, so when updating to libpng-1.4, /usr/lib/libpng.so.1.2 will be kept and added to the list of managed files in libpng-1.4 too, even though it wan't there at packaging time. I know that this is not the best technical solution, but it would satisfy both sides. Of course, that would require some implementation on pacman, but I'm just throwing my opinion. By the way, i never had any issues with upgrades in official packages, just my own compiled ones. I recompiled them and am happy rolling on :) -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Mon, Feb 8, 2010 at 10:54 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
Just one crazy idea that crossed my mind...
It would be very nice if we could mark some files in a package so that when updating the package, they would not be removed and, instead, would be added to the list of files belonging to that package.
Let's say: in libpng, /usr/lib/libpng.so.1.2 will be marked as such, so when updating to libpng-1.4, /usr/lib/libpng.so.1.2 will be kept and added to the list of managed files in libpng-1.4 too, even though it wan't there at packaging time.
I know that this is not the best technical solution, but it would satisfy both sides. Of course, that would require some implementation on pacman, but I'm just throwing my opinion.
Some more thinking about it... Of course, as the time goes by, there would be lots of old libraries trashing the system, but it would be possible to make some tool to remove unused ones, in the same principle of the tools used to trace packages needing recompiling. Yeah, crazy... but can we? -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
participants (4)
-
Allan McRae
-
Denis A. Altoé Falqueto
-
Nagy Gabor
-
vlad