On Wed, Mar 10, 2010 at 11:45 PM, Allan McRae wrote:
>
> Not really...
>
> The problem is that pacman does not clean up packages installed as a
> dependency for a package that are no longer needed due to an update which
> removed that dep.
>
And by the way, we cannot be 100% sure that the 'no lon
On Thu, 11 Mar 2010 08:45:17 +1000
Allan McRae wrote:
> On 11/03/10 08:22, Daenyth Blank wrote:
> > On Wed, Mar 10, 2010 at 16:54, clemens fischer
> > wrote:
> >> I always use "pacman -Rs". It's a wrapper script, I normally
> >> don't use a bare "pacman", so there's not even neglect at play.
>
On 11/03/10 08:22, Daenyth Blank wrote:
On Wed, Mar 10, 2010 at 16:54, clemens fischer
wrote:
I always use "pacman -Rs". It's a wrapper script, I normally don't use
a bare "pacman", so there's not even neglect at play.
That's the problem. You want to add -c. -s removes in one direction,
-c
On Wed, Mar 10, 2010 at 16:54, clemens fischer
wrote:
> I always use "pacman -Rs". It's a wrapper script, I normally don't use
> a bare "pacman", so there's not even neglect at play.
>
That's the problem. You want to add -c. -s removes in one direction,
-c removes in the other.
Nathan Wayde wrote:
> On 10/03/10 20:03, clemens fischer wrote:
>
>> Ironically, if pacman was such a tidy package manager and devs were
>> so keen to keep things that way, why is there ever any output in
>> "pacman -Qdt"?
>
> Could it be because you explicitly requested that? i.e `pacman -R
> pkg
On 10/03/10 20:03, clemens fischer wrote:
[...]
Ironically, if pacman was such a tidy package manager and devs were so
keen to keep things that way, why is there ever any output in "pacman
-Qdt"?
clemens
Could it be because you explicitly requested that?
i.e `pacman -R pkgname` which remove
f...@... wrote:
> But then doing a full system upgrade (as advised on this list)
> completely locked up the machine - frozen screen, dead capslock led
> etc. No other choice but a power cycle, broken filesystems, and hours
> of work repairing them and putting bits and pieces back in place.
> I sti
>>> "make install" does it
>>
>> Called by pacman, I suppose. Anyway this is irrelevant.
>
> No. pacman does not build packages. It installs them
Depends how you look at it:
$ pacman -Qo `which makepkg`
/usr/bin/makepkg is owned by pacman 3.3.3-1
so maybe pacman the command doesn't build package
On Mon, Feb 8, 2010 at 5:45 PM, wrote:
> On Mon, Feb 08, 2010 at 05:37:31PM -0600, Aaron Griffin wrote:
>
>> "make install" does it
>
> Called by pacman, I suppose. Anyway this is irrelevant.
No. pacman does not build packages. It installs them
On 9 February 2010 17:50, Xavier Chantry wrote:
> On Tue, Feb 9, 2010 at 3:19 AM, Arvid Picciani wrote:
>>
>> if someone actually posts patches or other constructive stuff, please CC
>> me. We're rewriting pacman anyway and looking for a solution to handle
>> this mess in particular.
>>
>> Right
On Tue, Feb 9, 2010 at 11:08 AM, Allan McRae wrote:
> On 09/02/10 19:50, Xavier Chantry wrote:
>>
>> Anyway, care to explain what you are rewriting pacman for ? There are
>> probably plenty of good reasons to do that, I am just curious to know
>> if you have any:)
>>
>
> I guess it is for some ide
On 09/02/10 19:50, Xavier Chantry wrote:
Anyway, care to explain what you are rewriting pacman for ? There are
probably plenty of good reasons to do that, I am just curious to know
if you have any:)
I guess it is for some ideas here:
http://www.hereticlinux.org/wiki/pacideas
On Tue, Feb 9, 2010 at 3:19 AM, Arvid Picciani wrote:
>
> if someone actually posts patches or other constructive stuff, please CC
> me. We're rewriting pacman anyway and looking for a solution to handle
> this mess in particular.
>
> Right now the only idea i got is versioned deps which is sort o
Le Tue, 09 Feb 2010 03:05:14 +,
Mauro Santos a écrit :
> > I'm facing a decision to change five 'critical' machines
> > in need of an upgrade to Arch or not. Over the last months
> > I've installed Arch on three less critical ones to get to
> > know the system. Up to yesterday the decision lo
Le Tue, 9 Feb 2010 09:12:29 +0100,
f...@kokkinizita.net a écrit :
> On Mon, Feb 08, 2010 at 08:02:04PM -0700, Brendan Long wrote:
>
> > Except then you'd annoy everyone who wants their package manager to work
> > properly. When I update a package I expect it to clean up after itself.
>
> Work pr
On Mon, Feb 08, 2010 at 08:02:04PM -0700, Brendan Long wrote:
> Except then you'd annoy everyone who wants their package manager to work
> properly. When I update a package I expect it to clean up after itself.
Work properly = not remove things that are still needed.
Clean up after itself = remov
On Tuesday 09 February 2010 08:32:04 Brendan Long wrote:
> On 02/08/2010 07:50 PM, f...@kokkinizita.net wrote:
> > One very simple solution would be to never delete anything
> > named /usr/lib/*.so* unless you really have to. That requires
> > one regexp match. A hack, not perfect but it would help
On Tue, Feb 9, 2010 at 1:49 PM, Eric Bélanger wrote:
> On Mon, Feb 8, 2010 at 8:52 PM, hollunder wrote:
[snip]
>
> As far as mirror are concernced, we (the devs) are aware of the
> problem and knew that the move of the rebuild out of testing would
> create havoc on the mirrors. However, we are wo
> I'm facing a decision to change five 'critical' machines
> in need of an upgrade to Arch or not. Over the last months
> I've installed Arch on three less critical ones to get to
> know the system. Up to yesterday the decision looked quite
> clear
Then maybe you should select something that gives
On 02/08/2010 07:50 PM, f...@kokkinizita.net wrote:
>> It would be interesting to try to patch yaourt to do what you're wanting
>> though. The simplest solution I can think of is some sort of script that
>> finds out which files in a package are libraries (probably something
>> simple like looking
I guess this is not going to change, Fons.
So, may I make one suggestion?
You could create a script to do the following:
1) rsync your /usr/lib to something like /libsforever
2) run pacman with provided arguments from commandline
3) rsync back whats in /libsforever to /usr/lib skipping older fi
On Mon, Feb 08, 2010 at 07:36:55PM -0700, Brendan Long wrote:
> On 02/08/2010 06:46 PM, f...@kokkinizita.net wrote:
> >
> >> It just knows that package (which contains application A0 requires
> >> package libfoo (which contains library libfoo.so.1).
> >>
> > In that case, play it safe and don
On Mon, Feb 8, 2010 at 8:52 PM, hollunder wrote:
> Excerpts from Brendan Long's message of 2010-02-09 02:09:13 +0100:
>> On 02/08/2010 05:50 PM, Allan McRae wrote:
>> > On 09/02/10 10:05, hollunder wrote:
>> >> Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
>> >>> On 09/02/10 04
On 02/08/2010 07:19 PM, Arvid Picciani wrote:
> On Sun, 10 Jan 2010 13:08:10 -0500, Jeff Horelick wrote:
>
>
> if someone actually posts patches or other constructive stuff, please CC
> me. We're rewriting pacman anyway and looking for a solution to handle
> this mess in particular.
>
> Right now
On Tue, Feb 09, 2010 at 02:21:58AM +0100, hollunder wrote:
> Fons ... runs critical systems and had apparently bigger problems.
I should mention that while there have been some problems
I am in general very satisfied with Arch, the documentation
and the support.
The really 'big' problem occured
On 02/08/2010 06:46 PM, f...@kokkinizita.net wrote:
>
>> It just knows that package (which contains application A0 requires
>> package libfoo (which contains library libfoo.so.1).
>>
> In that case, play it safe and don't remove anything that
> any app could depend on. It's better than making
On Sun, 10 Jan 2010 13:08:10 -0500, Jeff Horelick wrote:
if someone actually posts patches or other constructive stuff, please CC
me. We're rewriting pacman anyway and looking for a solution to handle
this mess in particular.
Right now the only idea i got is versioned deps which is sort of flaw
Le Tue, 09 Feb 2010 02:21:58 +0100,
hollunder a écrit :
> Maybe the issues are somewhere else? I don't know. One observation I, as
> a stinking normal user, could make is that there are few devs around
> where users hang out. Let's see.. I know of one dev active in #archlinux
> on IRC and about t
Excerpts from Brendan Long's message of 2010-02-09 02:09:13 +0100:
> On 02/08/2010 05:50 PM, Allan McRae wrote:
> > On 09/02/10 10:05, hollunder wrote:
> >> Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
> >>> On 09/02/10 04:49, Xavier Chantry wrote:
> With every big rebuild
On Mon, Feb 08, 2010 at 11:30:39PM -0200, Denis A. Altoé Falqueto wrote:
> On Mon, Feb 8, 2010 at 11:20 PM, wrote:
> > But then: pacman knows that A is installed and
> > depends on libfoo.so.1. But still it removes
> > that library. Why ? I'd just say it fails to
> > do its job, part of which is
On Mon, Feb 8, 2010 at 11:20 PM, wrote:
> But then: pacman knows that A is installed and
> depends on libfoo.so.1. But still it removes
> that library. Why ? I'd just say it fails to
> do its job, part of which is being aware of
> dependencies.
In fact, pacman doesn't know that application A nee
On Mon, Feb 08, 2010 at 05:56:31PM -0700, Brendan Long wrote:
> Why are you even using Arch?
Because it allows me to get recent versions of apps,
it doesn't force me to install a desktop I don't want,
and some other reasons.
> You sound like the kind of person who would want a
> "stable" distro
Excerpts from Allan McRae's message of 2010-02-09 01:50:02 +0100:
> On 09/02/10 10:05, hollunder wrote:
> > Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
> >> On 09/02/10 04:49, Xavier Chantry wrote:
> >>> With every big rebuilds we get new breakage stories. It seems like
> >>>
On 02/08/2010 05:36 PM, f...@kokkinizita.net wrote:
He may want *not* to update a particular package
for any good reason (reported regression, adding
unwanted dependencies, user base resistance, ...)
while still wanting to install a new one that
requires a new library version.
The ability to
Le Tue, 09 Feb 2010 09:26:37 +1000,
Allan McRae a écrit :
> 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?
That looks obvious to me. Pacman has been working the same w
On 02/08/2010 05:50 PM, Allan McRae wrote:
On 09/02/10 10:05, hollunder wrote:
Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
On 09/02/10 04:49, Xavier Chantry wrote:
With every big rebuilds we get new breakage stories. It seems like
it's the norm nowadays rather than the ex
On Mon, Feb 8, 2010 at 10:54 PM, Denis A. Altoé Falqueto
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 belong
On 02/08/2010 04:05 PM, f...@kokkinizita.net wrote:
On Mon, Feb 08, 2010 at 04:38:46PM -0600, Aaron Griffin wrote:
A package is not a single .so file, unless that is your proposal - to
split all .so files into their own packages.
Here is a list of files that would conflict if this was done
On 02/08/2010 04:49 PM, f...@kokkinizita.net wrote:
On Mon, Feb 08, 2010 at 06:42:56PM -0500, dave reisner wrote:
On Mon, Feb 8, 2010 at 6:26 PM, wrote:
In other words, do not *force* a user to update all
app using a library just because one of them requires
a newer version. Doing th
On Mon, Feb 8, 2010 at 10:46 PM, Allan McRae 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. Version
On 09/02/10 10:36, f...@kokkinizita.net wrote:
On Mon, Feb 08, 2010 at 05:06:07PM -0700, Brendan Long wrote:
But wouldn't the optimal solution be doing the depends correctly on
every package, so when your really slow user tries to update
Firefox, it correctly informs them that they need to upda
On 09/02/10 10:05, hollunder wrote:
Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
On 09/02/10 04:49, Xavier Chantry 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
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
On 09/02/10 09:57, f...@kokkinizita.net wrote:
A binary of an app depends on the*major* version of a
library. Updates that do not change the major version
must be backward compatible.
Hahahahaha... how naive...
Try packaging for a distro for a while and see how that breaks in practice.
On Mon, Feb 08, 2010 at 05:06:07PM -0700, Brendan Long wrote:
> But wouldn't the optimal solution be doing the depends correctly on
> every package, so when your really slow user tries to update
> Firefox, it correctly informs them that they need to update
> everything to do that?
That could plac
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
The thing is:
1) Since arch is a rolling release, the package of a library is named
such as 'libpng' and not 'libpng-1.1' or 'libpng-1.2', as at any given time
only the latest package should exist in the system.
2) The files and symlinks are created during the package building
process and the pac
On Tue, Feb 09, 2010 at 01:07:18AM +0100, f...@kokkinizita.net wrote:
> On Tue, Feb 09, 2010 at 09:49:50AM +1000, Allan McRae wrote:
>
> > We only support the latest packages in the repos, so if you have
> > issues with old versions of packages or packages from unsupported
> > sources, then it is
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
>> distributi
Excerpts from Brendan Long's message of 2010-02-09 01:06:07 +0100:
> On 02/08/2010 04:48 PM, Jan de Groot wrote:
> > On Mon, 2010-02-08 at 13:37 -0700, Brendan Long wrote:
> >
> >> Couldn't the piecemeal update problem be fixed by just putting
> >> version
> >> numbers in the depends() section
On Tue, Feb 09, 2010 at 09:49:50AM +1000, Allan McRae wrote:
> We only support the latest packages in the repos, so if you have
> issues with old versions of packages or packages from unsupported
> sources, then it is up to _you_ to fix them.
I don't have issues with them, except that they get
de
On 02/08/2010 04:48 PM, Jan de Groot wrote:
On Mon, 2010-02-08 at 13:37 -0700, Brendan Long wrote:
Couldn't the piecemeal update problem be fixed by just putting
version
numbers in the depends() section in each updated package, so for the
libpng rebuild for example, depends(... libpng>=#.#)?
Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
> On 09/02/10 04:49, Xavier Chantry 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
On Tue, Feb 09, 2010 at 12:48:21AM +0100, Jan de Groot wrote:
> On Mon, 2010-02-08 at 13:37 -0700, Brendan Long wrote:
> > Couldn't the piecemeal update problem be fixed by just putting
> > version
> > numbers in the depends() section in each updated package, so for the
> > libpng rebuild for ex
On Mon, Feb 8, 2010 at 9:45 PM, wrote:
> On Mon, Feb 08, 2010 at 05:37:31PM -0600, Aaron Griffin wrote:
>
> > "make install" does it
>
> Called by pacman, I suppose. Anyway this is irrelevant.
>
Two times wrong. It is not called by pacman and it is not irrelevant.
--
Guilherme M. Nogueira
"Any
On Mon, Feb 08, 2010 at 06:42:56PM -0500, dave reisner wrote:
> On Mon, Feb 8, 2010 at 6:26 PM, wrote:
> >
> > In other words, do not *force* a user to update all
> > app using a library just because one of them requires
> > a newer version. Doing this leaves the user with a
> > broken system, pos
On Mon, Feb 08, 2010 at 05:37:31PM -0600, Aaron Griffin wrote:
> "make install" does it
Called by pacman, I suppose. Anyway this is irrelevant.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
On Mon, 2010-02-08 at 13:37 -0700, Brendan Long wrote:
> Couldn't the piecemeal update problem be fixed by just putting
> version
> numbers in the depends() section in each updated package, so for the
> libpng rebuild for example, depends(... libpng>=#.#)? It would fix
> the
> problem in the mos
On 09/02/10 09:26, f...@kokkinizita.net wrote:
On Tue, Feb 09, 2010 at 09:18:00AM +1000, Allan McRae wrote:
I think you miss a point here. After a rebuild NONE of the packages
in the repos depend on the old library. So there is no point in us
packaging the old library for compatibilty, as non
On Tue, Feb 09, 2010 at 12:39:32AM +0100, vlad wrote:
> The idea of a rolling distro also applies to the AUR.
> The AUR as a part of Arch is as "rooling" as Arch is.
> Btw, there are workarounds like "libpng12" in the AUR, if you don't want
> to rebuild all of your own built application.
Again,
> So what ? An update should create/adjust that symlink
> and it currently does. There's no problem with that.
> Just don't delete the old *.so, that's all I ask.
Patch pacman, build your version, and add pacman to IgnorePkg
On Mon, Feb 8, 2010 at 5:39 PM, wrote:
> On Mon, Feb 08, 2010 at 05:37:19PM -0600, Muhammed Uluyol wrote:
>> > So *who* creates the symlink from libfoo.so ->
>> > libfoo.so.1.2.3 ? It's either pacman or ldconfig
>> > called by pacman. Unless you believe in little
>> > gremlins doing it while you
On Mon, Feb 08, 2010 at 05:37:19PM -0600, Muhammed Uluyol wrote:
> > So *who* creates the symlink from libfoo.so ->
> > libfoo.so.1.2.3 ? It's either pacman or ldconfig
> > called by pacman. Unless you believe in little
> > gremlins doing it while you sleep.
>
> It is created 'inside' of the packa
On Mon, Feb 8, 2010 at 6:26 PM, wrote:
>
> In other words, do not *force* a user to update all
> app using a library just because one of them requires
> a newer version. Doing this leaves the user with a
> broken system, possibly at the most inconvenient time.
Arch doesn't force you to update. I
On Tue, Feb 09, 2010 at 12:27:57AM +0100, vlad wrote:
> On Mon, Feb 08, 2010 at 11:54:43PM +0100, f...@kokkinizita.net wrote:
> > On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
> >
> > > you are focusing only on .so which is different but this schema will
> > > work only if the packa
On Tue, Feb 09, 2010 at 12:26:59AM +0100, f...@kokkinizita.net wrote:
> On Tue, Feb 09, 2010 at 09:18:00AM +1000, Allan McRae wrote:
>
> > I think you miss a point here. After a rebuild NONE of the packages
> > in the repos depend on the old library. So there is no point in us
> > packaging the
On Mon, Feb 8, 2010 at 5:20 PM, wrote:
> On Mon, Feb 08, 2010 at 05:17:15PM -0600, Aaron Griffin wrote:
>
>> On Mon, Feb 8, 2010 at 4:54 PM, wrote:
>> > On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
>> >
>> >> you are focusing only on .so which is different but this schema will
>>
> So *who* creates the symlink from libfoo.so ->
> libfoo.so.1.2.3 ? It's either pacman or ldconfig
> called by pacman. Unless you believe in little
> gremlins doing it while you sleep.
It is created 'inside' of the package, not during the installation.
$ bsdtar tzf libpng-1.4.0-2-x86_64.pkg.tar.
On Tue, Feb 09, 2010 at 09:18:00AM +1000, Allan McRae wrote:
> I think you miss a point here. After a rebuild NONE of the packages
> in the repos depend on the old library. So there is no point in us
> packaging the old library for compatibilty, as none is needed. We
> only support the latest p
On Mon, Feb 08, 2010 at 11:54:43PM +0100, f...@kokkinizita.net wrote:
> On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
>
> > you are focusing only on .so which is different but this schema will
> > work only if the package is split in lib, -dev, whatever as now, the
> > headers will c
On 09/02/10 04:49, Xavier Chantry 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
dis
On Mon, Feb 08, 2010 at 05:17:15PM -0600, Aaron Griffin wrote:
> On Mon, Feb 8, 2010 at 4:54 PM, wrote:
> > On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
> >
> >> you are focusing only on .so which is different but this schema will
> >> work only if the package is split in lib, -de
On Mon, Feb 08, 2010 at 11:07:41PM +, Pierre Chapuis wrote:
> Le Mon, 8 Feb 2010 23:29:48 +0100,
> f...@kokkinizita.net a écrit :
>
> > *** There is no conflict. *** Pacman can forget
> > about and even delete the package that supplied
> > the old version. It just *should not remove the
> > ol
On 09/02/10 08:54, f...@kokkinizita.net wrote:
On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
you are focusing only on .so which is different but this schema will
work only if the package is split in lib, -dev, whatever as now, the
headers will conflict since it have the same name
On Mon, Feb 8, 2010 at 4:54 PM, wrote:
> On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
>
>> you are focusing only on .so which is different but this schema will
>> work only if the package is split in lib, -dev, whatever as now, the
>> headers will conflict since it have the same na
On Mon, Feb 08, 2010 at 04:38:46PM -0600, Aaron Griffin wrote:
> A package is not a single .so file, unless that is your proposal - to
> split all .so files into their own packages.
>
> Here is a list of files that would conflict if this was done with libpng:
> libpng /usr/bin/libpng-config
> lib
Le Mon, 8 Feb 2010 23:29:48 +0100,
f...@kokkinizita.net a écrit :
> *** There is no conflict. *** Pacman can forget
> about and even delete the package that supplied
> the old version. It just *should not remove the
> old library itself*.
And you end up with .so files not tracked by Pacman in you
http://wiki.archlinux.org/index.php/The_Arch_Way#Code-correctness_over_convenience
On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
> you are focusing only on .so which is different but this schema will
> work only if the package is split in lib, -dev, whatever as now, the
> headers will conflict since it have the same name on the same
> location.
Not true. When a ne
On Mon, Feb 8, 2010 at 4:29 PM, wrote:
> On Mon, Feb 08, 2010 at 03:47:47PM -0600, Aaron Griffin wrote:
>
>> When I attempt to install app-baz, which pulls in libfoo 2.0, how do
>> you expect to resolve all the conflicts that result from keeping
>> libfoo 1.0 on the system at the same time as lib
On 02/09/2010 12:29 AM, f...@kokkinizita.net wrote:
On Mon, Feb 08, 2010 at 03:47:47PM -0600, Aaron Griffin wrote:
When I attempt to install app-baz, which pulls in libfoo 2.0, how do
you expect to resolve all the conflicts that result from keeping
libfoo 1.0 on the system at the same time as l
On Mon, Feb 08, 2010 at 03:47:47PM -0600, Aaron Griffin wrote:
> When I attempt to install app-baz, which pulls in libfoo 2.0, how do
> you expect to resolve all the conflicts that result from keeping
> libfoo 1.0 on the system at the same time as libfoo 2.0? All sorts of
> things are in conflict
Aaron Griffin wrote:
On Mon, Feb 8, 2010 at 3:36 PM, wrote:
On Mon, Feb 08, 2010 at 04:19:04PM -0500, Ray Kohler wrote:
It is *required* to do only complete system updates when using Arch.
Partial updates are not supported, *by design*.
If that is true, which I refuse to beli
On Mon, Feb 8, 2010 at 3:36 PM, wrote:
> On Mon, Feb 08, 2010 at 04:19:04PM -0500, Ray Kohler wrote:
>
>> It is *required* to do only complete system updates when using Arch.
>> Partial updates are not supported, *by design*.
>
> If that is true, which I refuse to believe, it means
> that Arch is
On Mon, Feb 08, 2010 at 04:19:04PM -0500, Ray Kohler wrote:
> It is *required* to do only complete system updates when using Arch.
> Partial updates are not supported, *by design*.
If that is true, which I refuse to believe, it means
that Arch is a toy system only suitable for kids who
take a kic
On Mon, Feb 8, 2010 at 4:04 PM, wrote:
> If I notice that a new app or an update of an existing one
> has included a new major version of a library, I will in time
> probably update or recompile everything to use the new library
> as well. It would typically be a matter of some days.
>
> Just do
On Tue, Feb 09, 2010 at 03:09:00AM +0800, Ray Rashif wrote:
> I really like the sodepends/soprovides idea, especially after the last
> discussion. After this one, I like it even more. The libfoo2/3/4 has
> always confused me, and is one of the reasons why our repos appear
> "cleaner" and are, in e
On 02/08/2010 11:56 AM, Ray Kohler wrote:
On Mon, Feb 8, 2010 at 1:49 PM, Xavier Chantry 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 i
On 9 February 2010 02:49, Xavier Chantry 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
Keeping old versions of libs would violate Arch's policy of being bleeding
edge and also complicate things. -1 from me.
On Feb 8, 2010 2:03 PM, "Thomas Bächler" wrote:
Am 08.02.2010 19:56, schrieb Ray Kohler:
> I haven't seen a single reported problem from any of the recent big
> rebuilds that
Am 08.02.2010 19:56, schrieb Ray Kohler:
> I haven't seen a single reported problem from any of the recent big
> rebuilds that wasn't the result of a user doing something they ought
> not to do (usually piecemeal updates), an out-of-sync mirror (plus
> users that can't even recognize this when they
On Mon, Feb 8, 2010 at 1:49 PM, Xavier Chantry 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
On Mon, Jan 11, 2010 at 12:53 AM, Aaron Griffin wrote:
> On Sun, Jan 10, 2010 at 12:08 PM, Jeff Horelick wrote:
>> Hey all,
>>
>> I have a suggestion to possibly make rebuilds a bit less painful (or
>> non-existant). I think this is a good idea because it seems like right now,
>> even before ther
On Sun, Jan 10, 2010 at 12:08 PM, Jeff Horelick wrote:
> Hey all,
>
> I have a suggestion to possibly make rebuilds a bit less painful (or
> non-existant). I think this is a good idea because it seems like right now,
> even before there was a new rebuild (ffmpeg/x264) in testing, there's
> already
On Sun, Jan 10, 2010 at 01:08:10PM -0500, Jeff Horelick wrote:
> Hey all,
>
> I have a suggestion to possibly make rebuilds a bit less painful (or
> non-existant). I think this is a good idea because it seems like right now,
> even before there was a new rebuild (ffmpeg/x264) in testing, there's
>
On Sun, Jan 10, 2010 at 7:34 PM, Jeff Horelick wrote:
>
> 2. pacman -Qm has 2 flaws that i see. For one, it'll also list all your AUR
> packages, it'd be nice to maybe just list packages that were installed from
> the repos but are no longer there and ignore any manually installed
> packages. For
2010/1/10 Xavier
> On Sun, Jan 10, 2010 at 7:08 PM, Jeff Horelick wrote:
> > This would likely require 2 changes to pacman to implement:
> > 1. Pacman would have to know that libpng8 is the newer version of libpng7
> > and prompt users to install that (or do it as a upgrade keeping the old
> > p
On Sun, Jan 10, 2010 at 7:08 PM, Jeff Horelick wrote:
> This would likely require 2 changes to pacman to implement:
> 1. Pacman would have to know that libpng8 is the newer version of libpng7
> and prompt users to install that (or do it as a upgrade keeping the old
> package).
Is that needed ? Ne
Hey all,
I have a suggestion to possibly make rebuilds a bit less painful (or
non-existant). I think this is a good idea because it seems like right now,
even before there was a new rebuild (ffmpeg/x264) in testing, there's
already another on the horizon (linjpeg/libpng, and it's a big one) and wh
99 matches
Mail list logo
