Re: [pacman-dev] Disk space checking branch complete
On Tue, Nov 16, 2010 at 06:06:32PM -0600, Dan McGee wrote:
On Tue, Nov 16, 2010 at 5:36 PM, Allan McRae al...@archlinux.org wrote:
On 17/11/10 03:25, Nezmer wrote:
On Tue, Nov 16, 2010 at 09:03:37PM +1000, Allan McRae wrote:
On 16/11/10 18:02, Bryce Gibson wrote:
Hi Allan,
I just wanted to ask, it looks like your patches will make a sync fail
if it
finds there's not enough space, is that correct?
Because I'd suggest a warning may be more appropriate, especially for
use
cases like compressed filesystems.
Cheers
Bryce
ps. I noticed that space checking can be completely disabled via
pacman.conf, which may be seen as a suitable solution for people in
these
types of situation.
Disabling checking in pacman.conf is what I would recommend in these
sort of cases. These are the sort of things we will only find out
after we get some widespread usage of the feature. I would be
interested in what the size calculations actually do on compressed
filesystems.
Allan
On the topic of FS compression(also FS caching and delayed allocation).
The real issue I had was the calculation of install size when building
the package. The calculated size was always *very* small. I addressed
this issue with 2 patches. The 1st one (adding sync before running du)
didn't fix anything. The 2nd patch worked pretty well.
http://gitorious.org/pacman-bsd/pacman-bsd/commit/8b367d4441ba85b5548285d987afcfc84c4fcb3e
http://gitorious.org/pacman-bsd/pacman-bsd/commit/cf3341fe591293a493bc925e0433a1f696b37d90
I think that initial sync is not needed because du does one anyway. The
second one looks interesting so I have bookmarked it to look at later.
We've putzed around with this a few times, haven't we? This basically
reverts this one:
commit 149839c5391e9a93465f86dbb8d095a0150d755d
Author: Xavier Chantry shinin...@gmail.com
Date: Mon May 26 23:46:01 2008 +0200
du -b is not available on BSD, use du -k instead.
This fixes FS#10459.
There is apparently no portable ways to get the apparent size of a file,
like du -b does. So the best compromise seems to get the block size in kB,
and then convert that to byte so that we keep compatibility.
Signed-off-by: Xavier Chantry shinin...@gmail.com
Signed-off-by: Dan McGee d...@archlinux.org
There are three or so file sizes that matter:
1) du -s : what we do now, sums up actual taken space so would be more
accurate with many 4K files.
2) du -sb: what we did before and what is proposed, sums up apparent
size, so does not necessarily best represent installed size (either
sparse files or many 4K files would throw the number off). The 4K
assumption also may not always hold...
3) du --tell-me-how-many-blocks-but-not-compressed : what seems like
perhaps the ideal? I'm not sure, but this would basically
for file in tree:
total += ceil(filesize to 4K)
1 is the most portable; 2 we need different flags all over the place;
3 we definitely don't seem to be able to use exiting tools but this
would not be an awful one to write.
-Dan
Is this 3 ?
install_size=0
for f in `find $pkgdir -type f`; do
(( s=$(${SIZECMD} ${f})/1024 ))
(( $(${SIZECMD} ${f})%1024 0 )) (( s++ ))
(( $s 4 )) (( s=4 ))
(( install_size+=${s} ))
done
Unfortunately, this takes around 39 seconds in a 13085 files package.
Re: [pacman-dev] Disk space checking branch complete
On Wed, Nov 17, 2010 at 12:13 PM, Nezmer g...@nezmer.info wrote:
On Tue, Nov 16, 2010 at 06:06:32PM -0600, Dan McGee wrote:
On Tue, Nov 16, 2010 at 5:36 PM, Allan McRae al...@archlinux.org wrote:
On 17/11/10 03:25, Nezmer wrote:
On Tue, Nov 16, 2010 at 09:03:37PM +1000, Allan McRae wrote:
On 16/11/10 18:02, Bryce Gibson wrote:
Hi Allan,
I just wanted to ask, it looks like your patches will make a sync fail
if it
finds there's not enough space, is that correct?
Because I'd suggest a warning may be more appropriate, especially for
use
cases like compressed filesystems.
Cheers
Bryce
ps. I noticed that space checking can be completely disabled via
pacman.conf, which may be seen as a suitable solution for people in
these
types of situation.
Disabling checking in pacman.conf is what I would recommend in these
sort of cases. These are the sort of things we will only find out
after we get some widespread usage of the feature. I would be
interested in what the size calculations actually do on compressed
filesystems.
Allan
On the topic of FS compression(also FS caching and delayed allocation).
The real issue I had was the calculation of install size when building
the package. The calculated size was always *very* small. I addressed
this issue with 2 patches. The 1st one (adding sync before running du)
didn't fix anything. The 2nd patch worked pretty well.
http://gitorious.org/pacman-bsd/pacman-bsd/commit/8b367d4441ba85b5548285d987afcfc84c4fcb3e
http://gitorious.org/pacman-bsd/pacman-bsd/commit/cf3341fe591293a493bc925e0433a1f696b37d90
I think that initial sync is not needed because du does one anyway. The
second one looks interesting so I have bookmarked it to look at later.
We've putzed around with this a few times, haven't we? This basically
reverts this one:
commit 149839c5391e9a93465f86dbb8d095a0150d755d
Author: Xavier Chantry shinin...@gmail.com
Date: Mon May 26 23:46:01 2008 +0200
du -b is not available on BSD, use du -k instead.
This fixes FS#10459.
There is apparently no portable ways to get the apparent size of a file,
like du -b does. So the best compromise seems to get the block size in
kB,
and then convert that to byte so that we keep compatibility.
Signed-off-by: Xavier Chantry shinin...@gmail.com
Signed-off-by: Dan McGee d...@archlinux.org
There are three or so file sizes that matter:
1) du -s : what we do now, sums up actual taken space so would be more
accurate with many 4K files.
2) du -sb: what we did before and what is proposed, sums up apparent
size, so does not necessarily best represent installed size (either
sparse files or many 4K files would throw the number off). The 4K
assumption also may not always hold...
3) du --tell-me-how-many-blocks-but-not-compressed : what seems like
perhaps the ideal? I'm not sure, but this would basically
for file in tree:
total += ceil(filesize to 4K)
1 is the most portable; 2 we need different flags all over the place;
3 we definitely don't seem to be able to use exiting tools but this
would not be an awful one to write.
-Dan
Is this 3 ?
install_size=0
for f in `find $pkgdir -type f`; do
(( s=$(${SIZECMD} ${f})/1024 ))
(( $(${SIZECMD} ${f})%1024 0 )) (( s++ ))
(( $s 4 )) (( s=4 ))
(( install_size+=${s} ))
done
Unfortunately, this takes around 39 seconds in a 13085 files package.
Sure, but we can write a 25 line C program to do the same thing in
about 1% of the time.
-Dan
Re: [pacman-dev] Disk space checking branch complete
On Wed, Nov 17, 2010 at 08:13:08PM +0200, Nezmer wrote:
On Tue, Nov 16, 2010 at 06:06:32PM -0600, Dan McGee wrote:
On Tue, Nov 16, 2010 at 5:36 PM, Allan McRae al...@archlinux.org wrote:
On 17/11/10 03:25, Nezmer wrote:
On Tue, Nov 16, 2010 at 09:03:37PM +1000, Allan McRae wrote:
On 16/11/10 18:02, Bryce Gibson wrote:
Hi Allan,
I just wanted to ask, it looks like your patches will make a sync fail
if it
finds there's not enough space, is that correct?
Because I'd suggest a warning may be more appropriate, especially for
use
cases like compressed filesystems.
Cheers
Bryce
ps. I noticed that space checking can be completely disabled via
pacman.conf, which may be seen as a suitable solution for people in
these
types of situation.
Disabling checking in pacman.conf is what I would recommend in these
sort of cases. These are the sort of things we will only find out
after we get some widespread usage of the feature. I would be
interested in what the size calculations actually do on compressed
filesystems.
Allan
On the topic of FS compression(also FS caching and delayed allocation).
The real issue I had was the calculation of install size when building
the package. The calculated size was always *very* small. I addressed
this issue with 2 patches. The 1st one (adding sync before running du)
didn't fix anything. The 2nd patch worked pretty well.
http://gitorious.org/pacman-bsd/pacman-bsd/commit/8b367d4441ba85b5548285d987afcfc84c4fcb3e
http://gitorious.org/pacman-bsd/pacman-bsd/commit/cf3341fe591293a493bc925e0433a1f696b37d90
I think that initial sync is not needed because du does one anyway. The
second one looks interesting so I have bookmarked it to look at later.
We've putzed around with this a few times, haven't we? This basically
reverts this one:
commit 149839c5391e9a93465f86dbb8d095a0150d755d
Author: Xavier Chantry shinin...@gmail.com
Date: Mon May 26 23:46:01 2008 +0200
du -b is not available on BSD, use du -k instead.
This fixes FS#10459.
There is apparently no portable ways to get the apparent size of a file,
like du -b does. So the best compromise seems to get the block size in
kB,
and then convert that to byte so that we keep compatibility.
Signed-off-by: Xavier Chantry shinin...@gmail.com
Signed-off-by: Dan McGee d...@archlinux.org
There are three or so file sizes that matter:
1) du -s : what we do now, sums up actual taken space so would be more
accurate with many 4K files.
2) du -sb: what we did before and what is proposed, sums up apparent
size, so does not necessarily best represent installed size (either
sparse files or many 4K files would throw the number off). The 4K
assumption also may not always hold...
3) du --tell-me-how-many-blocks-but-not-compressed : what seems like
perhaps the ideal? I'm not sure, but this would basically
for file in tree:
total += ceil(filesize to 4K)
1 is the most portable; 2 we need different flags all over the place;
3 we definitely don't seem to be able to use exiting tools but this
would not be an awful one to write.
-Dan
Is this 3 ?
install_size=0
for f in `find $pkgdir -type f`; do
(( s=$(${SIZECMD} ${f})/1024 ))
(( $(${SIZECMD} ${f})%1024 0 )) (( s++ ))
(( $s 4 )) (( s=4 ))
(( install_size+=${s} ))
done
Unfortunately, this takes around 39 seconds in a 13085 files package.
Correction:
install_size=0
for f in `find $pkgdir -type f`; do
(( s=$(${SIZECMD} ${f})/1024 ))
(( $(${SIZECMD} ${f})%1024 )) (( s++ ))
(( ${s}%4 )) (( s+=${s}%4 ))
(( install_size+=${s} ))
done
Takes around 40 seconds in a 13085 files package.
Re: [pacman-dev] Disk space checking branch complete
On Wed, Nov 17, 2010 at 08:22:14PM +0200, Nezmer wrote:
On Wed, Nov 17, 2010 at 08:13:08PM +0200, Nezmer wrote:
On Tue, Nov 16, 2010 at 06:06:32PM -0600, Dan McGee wrote:
On Tue, Nov 16, 2010 at 5:36 PM, Allan McRae al...@archlinux.org wrote:
On 17/11/10 03:25, Nezmer wrote:
On Tue, Nov 16, 2010 at 09:03:37PM +1000, Allan McRae wrote:
On 16/11/10 18:02, Bryce Gibson wrote:
Hi Allan,
I just wanted to ask, it looks like your patches will make a sync
fail
if it
finds there's not enough space, is that correct?
Because I'd suggest a warning may be more appropriate, especially for
use
cases like compressed filesystems.
Cheers
Bryce
ps. I noticed that space checking can be completely disabled via
pacman.conf, which may be seen as a suitable solution for people in
these
types of situation.
Disabling checking in pacman.conf is what I would recommend in these
sort of cases. These are the sort of things we will only find out
after we get some widespread usage of the feature. I would be
interested in what the size calculations actually do on compressed
filesystems.
Allan
On the topic of FS compression(also FS caching and delayed allocation).
The real issue I had was the calculation of install size when building
the package. The calculated size was always *very* small. I addressed
this issue with 2 patches. The 1st one (adding sync before running du)
didn't fix anything. The 2nd patch worked pretty well.
http://gitorious.org/pacman-bsd/pacman-bsd/commit/8b367d4441ba85b5548285d987afcfc84c4fcb3e
http://gitorious.org/pacman-bsd/pacman-bsd/commit/cf3341fe591293a493bc925e0433a1f696b37d90
I think that initial sync is not needed because du does one anyway.
The
second one looks interesting so I have bookmarked it to look at later.
We've putzed around with this a few times, haven't we? This basically
reverts this one:
commit 149839c5391e9a93465f86dbb8d095a0150d755d
Author: Xavier Chantry shinin...@gmail.com
Date: Mon May 26 23:46:01 2008 +0200
du -b is not available on BSD, use du -k instead.
This fixes FS#10459.
There is apparently no portable ways to get the apparent size of a
file,
like du -b does. So the best compromise seems to get the block size
in kB,
and then convert that to byte so that we keep compatibility.
Signed-off-by: Xavier Chantry shinin...@gmail.com
Signed-off-by: Dan McGee d...@archlinux.org
There are three or so file sizes that matter:
1) du -s : what we do now, sums up actual taken space so would be more
accurate with many 4K files.
2) du -sb: what we did before and what is proposed, sums up apparent
size, so does not necessarily best represent installed size (either
sparse files or many 4K files would throw the number off). The 4K
assumption also may not always hold...
3) du --tell-me-how-many-blocks-but-not-compressed : what seems like
perhaps the ideal? I'm not sure, but this would basically
for file in tree:
total += ceil(filesize to 4K)
1 is the most portable; 2 we need different flags all over the place;
3 we definitely don't seem to be able to use exiting tools but this
would not be an awful one to write.
-Dan
Is this 3 ?
install_size=0
for f in `find $pkgdir -type f`; do
(( s=$(${SIZECMD} ${f})/1024 ))
(( $(${SIZECMD} ${f})%1024 0 )) (( s++ ))
(( $s 4 )) (( s=4 ))
(( install_size+=${s} ))
done
Unfortunately, this takes around 39 seconds in a 13085 files package.
Correction:
install_size=0
for f in `find $pkgdir -type f`; do
(( s=$(${SIZECMD} ${f})/1024 ))
(( $(${SIZECMD} ${f})%1024 )) (( s++ ))
(( ${s}%4 )) (( s+=${s}%4 ))
(( install_size+=${s} ))
done
Takes around 40 seconds in a 13085 files package.
Fail
As Dan said, This is too slow to be done in bash. I just want to correct
it for reference.
install_size=0
for f in `find $pkgdir -type f`; do
(( s=$(${SIZECMD} ${f})/1024 ))
(( $(${SIZECMD} ${f})%1024 )) (( s++ ))
(( ${s}%4 )) (( s+=4-${s}%4 ))
(( install_size+=${s} ))
done
Re: [pacman-dev] Disk space checking branch complete
On Wed, Nov 17, 2010 at 1:06 AM, Dan McGee dpmc...@gmail.com wrote: We've putzed around with this a few times, haven't we? This basically reverts this one: commit 149839c5391e9a93465f86dbb8d095a0150d755d Author: Xavier Chantry shinin...@gmail.com Date: Mon May 26 23:46:01 2008 +0200 du -b is not available on BSD, use du -k instead. This fixes FS#10459. There is apparently no portable ways to get the apparent size of a file, like du -b does. So the best compromise seems to get the block size in kB, and then convert that to byte so that we keep compatibility. Signed-off-by: Xavier Chantry shinin...@gmail.com Signed-off-by: Dan McGee d...@archlinux.org It doesn't revert my commit, it just takes the alternative approach which was already suggested in the bug report : https://bugs.archlinux.org/task/10459#comment28616 We do this already for stat and sed, we do this in C (c.f. diskspace), so why not for du ? I've no problem with that. That said, I've no problem with a C impl either. Would it be portable ? Just wanted to mention that even though I wrote this patch, I am for restoring apparent size. IIRC we already got a report/request for that a while ago and I already felt that way back then.
[pacman-dev] Warn about using -Sy
Oftentimes, I come across people using `pacman -Sy name' to install new packages. This installs the latest version of a package, while leaving any required libraries at their old version. The introduction of an incompatibility between a package and its dependencies is highly possible. A recent example of this issue is [1]. Could you please review the attached tiny patch for code structure, language used, and overall approach? -- [1] http://mailman.archlinux.org/pipermail/arch-general/2010-November/017198.html
[pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
Doing so can lead to broken applications after soname bumps, or major
version upgrades like the transition to Python 3.
---
src/pacman/sync.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/pacman/sync.c b/src/pacman/sync.c
index f9d12e4..e7b7628 100644
--- a/src/pacman/sync.c
+++ b/src/pacman/sync.c
@@ -805,6 +805,14 @@ int pacman_sync(alpm_list_t *targets)
}
if(config-op_s_sync) {
+ /* Warn the user when synchronizing the package databases
without also
+* performing a full upgrade. */
+ if (!config-op_s_upgrade !noyes(_(:: Synchronizing the
package
+ databases without also performing a full
upgrade \n
+ :: can lead to software incompatibilities.
+ Continue anyway?))) {
+ return(0);
+ }
/* grab a fresh package list */
printf(_(:: Synchronizing package databases...\n));
alpm_logaction(synchronizing package lists\n);
--
1.7.3.2
Re: [pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
On Wed, Nov 17, 2010 at 2:46 PM, Evangelos Foutras foutre...@gmail.com wrote:
Doing so can lead to broken applications after soname bumps, or major
version upgrades like the transition to Python 3.
I have mixed feelings for sure on this. The intent is great, for
soure. But I do -Sy pkg a lot, knowing what is safe, what isn't.
This prompting would annoy the heck out of me. This also doesn't help
anyone that does an -Syu, cancels, and then later -S anything.
---
Side note- you sent another email; if you are just sending one patch
you can include those notes here below the '---' and it won't make it
into the final patch. So right here .:)
src/pacman/sync.c | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/pacman/sync.c b/src/pacman/sync.c
index f9d12e4..e7b7628 100644
--- a/src/pacman/sync.c
+++ b/src/pacman/sync.c
@@ -805,6 +805,14 @@ int pacman_sync(alpm_list_t *targets)
}
if(config-op_s_sync) {
+ /* Warn the user when synchronizing the package databases
without also
+ * performing a full upgrade. */
+ if (!config-op_s_upgrade !noyes(_(:: Synchronizing the
package
Too much going on in one if statement- I'd at least wrap it smarter
(before/after the , whatever is precedent), or make it nested
conditionals.
+ databases without also performing a full
upgrade \n
+ :: can lead to software incompatibilities.
+ Continue anyway?))) {
+ return(0);
+ }
/* grab a fresh package list */
printf(_(:: Synchronizing package databases...\n));
alpm_logaction(synchronizing package lists\n);
--
1.7.3.2
Re: [pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
Am Mittwoch 17 November 2010, 21:46:23 schrieb Evangelos Foutras:
Doing so can lead to broken applications after soname bumps, or major
version upgrades like the transition to Python 3.
---
src/pacman/sync.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/pacman/sync.c b/src/pacman/sync.c
index f9d12e4..e7b7628 100644
--- a/src/pacman/sync.c
+++ b/src/pacman/sync.c
@@ -805,6 +805,14 @@ int pacman_sync(alpm_list_t *targets)
}
if(config-op_s_sync) {
+ /* Warn the user when synchronizing the package databases
without also
+ * performing a full upgrade. */
+ if (!config-op_s_upgrade !noyes(_(:: Synchronizing the
package
+ databases without also performing a full
upgrade \n
+ :: can lead to software incompatibilities.
+ Continue anyway?))) {
+ return(0);
+ }
/* grab a fresh package list */
printf(_(:: Synchronizing package databases...\n));
alpm_logaction(synchronizing package lists\n);
Hello,
this patch introduces a question on every repository sync if a am right. So
that patch also asks if you type 'pacman -Syu' ? If it is i would not vote for
this patch, because it's another question you must acknoweledge every system
update.
If it only asks on 'pacman -Sy package' then its ok for me. Another
suggestion, only print this warning and don't ask. An arch user would read the
output of pacman and its package pre/post-scripts and is warned.
What do you think?
Re: [pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
On Wed, Nov 17, 2010 at 11:00 PM, Thomas Bahn thomas-b...@gmx.net wrote: this patch introduces a question on every repository sync if a am right. So that patch also asks if you type 'pacman -Syu' ? If it is i would not vote for this patch, because it's another question you must acknoweledge every system update. Nope, it only asks you if the -u switch is absent. In that case, the question is asked only once per sync operation. If it only asks on 'pacman -Sy package' then its ok for me. Another suggestion, only print this warning and don't ask. An arch user would read the output of pacman and its package pre/post-scripts and is warned. One problem I see with only printing a warning is that the user doesn't have the option not to synchronize at this point and just rerun pacman without the -y switch to install their package.
Re: [pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
On Wed, Nov 17, 2010 at 10:00 PM, Thomas Bahn thomas-b...@gmx.net wrote: this patch introduces a question on every repository sync if a am right. So that patch also asks if you type 'pacman -Syu' ? If it is i would not vote for this patch, because it's another question you must acknoweledge every system update. If it only asks on 'pacman -Sy package' then its ok for me. Another suggestion, only print this warning and don't ask. An arch user would read the output of pacman and its package pre/post-scripts and is warned. AFAI can see, it only asks for -Sy and -Sy targets
Re: [pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
Am Mittwoch 17 November 2010, 22:20:08 schrieb Evangelos Foutras: On Wed, Nov 17, 2010 at 11:00 PM, Thomas Bahn thomas-b...@gmx.net wrote: this patch introduces a question on every repository sync if a am right. So that patch also asks if you type 'pacman -Syu' ? If it is i would not vote for this patch, because it's another question you must acknoweledge every system update. Nope, it only asks you if the -u switch is absent. In that case, the question is asked only once per sync operation. ah, i didn't read the source carefully enough. ;) The meaning of config- op_s_upgrade is other than i assumed. If it only asks on 'pacman -Sy package' then its ok for me. Another suggestion, only print this warning and don't ask. An arch user would read the output of pacman and its package pre/post-scripts and is warned. One problem I see with only printing a warning is that the user doesn't have the option not to synchronize at this point and just rerun pacman without the -y switch to install their package. You are right, but as Dan McGee mentioned before it implies also that some 'special cases' even can lead to partial updates without the warning. The quote from his email: This also doesn't help anyone that does an -Syu, cancels, and then later -S anything. But i am not sure if we should catch such actions?
Re: [pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
On Wed, Nov 17, 2010 at 11:37 PM, Thomas Bahn thomas-b...@gmx.net wrote: Am Mittwoch 17 November 2010, 22:20:08 schrieb Evangelos Foutras: One problem I see with only printing a warning is that the user doesn't have the option not to synchronize at this point and just rerun pacman without the -y switch to install their package. You are right, but as Dan McGee mentioned before it implies also that some 'special cases' even can lead to partial updates without the warning. The quote from his email: This also doesn't help anyone that does an -Syu, cancels, and then later -S anything. But i am not sure if we should catch such actions? It is true that special cases exist. Unfortunately, I can't think of a way to handle them. I'm starting to think that printing a warning (like you suggested in a previous message) is a better alternative; we won't bother people with a question that doesn't catch all use cases, while still informing most offenders of the possible issues. If others agree that this is a preferred solution, I'll create a patch tomorrow. :)
Re: [pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
On Wed, Nov 17, 2010 at 11:53:56PM +0200, Evangelos Foutras wrote: On Wed, Nov 17, 2010 at 11:37 PM, Thomas Bahn thomas-b...@gmx.net wrote: Am Mittwoch 17 November 2010, 22:20:08 schrieb Evangelos Foutras: One problem I see with only printing a warning is that the user doesn't have the option not to synchronize at this point and just rerun pacman without the -y switch to install their package. You are right, but as Dan McGee mentioned before it implies also that some 'special cases' even can lead to partial updates without the warning. The quote from his email: This also doesn't help anyone that does an -Syu, cancels, and then later -S anything. But i am not sure if we should catch such actions? It is true that special cases exist. Unfortunately, I can't think of a way to handle them. I'm starting to think that printing a warning (like you suggested in a previous message) is a better alternative; we won't bother people with a question that doesn't catch all use cases, while still informing most offenders of the possible issues. If others agree that this is a preferred solution, I'll create a patch tomorrow. :) Can't we just let Darwin prevail? You don't keep touching the stove after the first time you find out it's hot... or maybe you do... dave
Re: [pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
On 18/11/10 06:59, Dan McGee wrote: On Wed, Nov 17, 2010 at 2:46 PM, Evangelos Foutrasfoutre...@gmail.com wrote: Doing so can lead to broken applications after soname bumps, or major version upgrades like the transition to Python 3. I have mixed feelings for sure on this. The intent is great, for soure. But I do -Sypkg a lot, knowing what is safe, what isn't. This prompting would annoy the heck out of me. This also doesn't help anyone that does an -Syu, cancels, and then later -Sanything. I have very strong feelings against this. This operation is perfectly fine, even recommended, on a non-rolling release distro. And we do have one of those using pacman (Arch Server - where I would -Sy and then review which packages to upgrade...). Allan
