[pacman-dev] Status Update for release
Xavier and I worked hard today to close out a few bugs and issues with pacman, including the bash <-> filesystem backup issue which should now be fixed (yay!). The DE translation has been updated as well. One of the final pacman-git builds before the release is out there: http://dev.archlinux.org/~dan/pacman-git/ PLEASE report any issues. I want to release 3.1.0 to testing early next week. I foresee a 3.1.1 release to core coming about a week or so later. Travis- I'll send you more details soon so we can get a corresponding abs package release together. Also of note is the spiffy new website that I threw together: http://archlinux.org/pacman/ All of our asciidoc-generated manpages are now up there, and the main page itself is also an asciidoc document. Enjoy! -Dan
On Jan 5, 2008 7:30 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Travis- I'll send you more details soon so we can get a corresponding abs package release together.
Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door. I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form. -- Travis
On Jan 6, 2008 9:18 PM, Travis Willard <travis@archlinux.org> wrote:
On Jan 5, 2008 7:30 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Travis- I'll send you more details soon so we can get a corresponding abs package release together.
Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.
Fine with me. The whole idea here was to decouple first, and then develop later. Might as well keep what works, even if not perfectly ideal.
I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.
Cool. Feel free to push it off to testing whenever you want. Can someone create a ftp directory called other/abs perhaps? That might make more sense than grouping it under pacman/. -Dan
On Jan 6, 2008 10:24 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Jan 6, 2008 9:18 PM, Travis Willard <travis@archlinux.org> wrote:
On Jan 5, 2008 7:30 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Travis- I'll send you more details soon so we can get a corresponding abs package release together.
Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.
Fine with me. The whole idea here was to decouple first, and then develop later. Might as well keep what works, even if not perfectly ideal.
I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.
Cool. Feel free to push it off to testing whenever you want. Can someone create a ftp directory called other/abs perhaps? That might make more sense than grouping it under pacman/.
Writable by the abs-git group? :)
On 1/7/08, Travis Willard <travis@archlinux.org> wrote:
On Jan 6, 2008 10:24 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Jan 6, 2008 9:18 PM, Travis Willard <travis@archlinux.org> wrote:
On Jan 5, 2008 7:30 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Travis- I'll send you more details soon so we can get a corresponding abs package release together.
Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.
Fine with me. The whole idea here was to decouple first, and then develop later. Might as well keep what works, even if not perfectly ideal.
I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.
Cool. Feel free to push it off to testing whenever you want. Can someone create a ftp directory called other/abs perhaps? That might make more sense than grouping it under pacman/.
Writable by the abs-git group? :)
oh. I forgot to reply. Dan caught me on jabber last night and prodded me to get this done. So you should now find the /ftp/other/abs/ directory, and it should have appropriate user/group permissions.
On Jan 7, 2008 11:38 AM, eliott <eliott@cactuswax.net> wrote:
On Jan 6, 2008 10:24 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Jan 6, 2008 9:18 PM, Travis Willard <travis@archlinux.org> wrote:
On Jan 5, 2008 7:30 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Travis- I'll send you more details soon so we can get a corresponding abs package release together.
Just an FYI - I'll be releasing this ABS as the old 'cvsup' version
On 1/7/08, Travis Willard <travis@archlinux.org> wrote: -
I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.
Fine with me. The whole idea here was to decouple first, and then develop later. Might as well keep what works, even if not perfectly ideal.
I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.
Cool. Feel free to push it off to testing whenever you want. Can someone create a ftp directory called other/abs perhaps? That might make more sense than grouping it under pacman/.
Writable by the abs-git group? :)
oh. I forgot to reply. Dan caught me on jabber last night and prodded me to get this done. So you should now find the /ftp/other/abs/ directory, and it should have appropriate user/group permissions.
Noticed that this morning when I was mucking around getting a tarball ready for release. Thanks eliott.
On Jan 6, 2008 9:18 PM, Travis Willard <travis@archlinux.org> wrote:
On Jan 5, 2008 7:30 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Travis- I'll send you more details soon so we can get a corresponding abs package release together.
Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.
I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.
Final update of pacman-git tonight so it can be installed side-by-side with testing/abs. PLEASE report anything, otherwise source tarball release happens tomorrow. Slight updates to the webpage too: http://www.archlinux.org/pacman/, and notably to the translation-help file. I'll be looking for a translation lieutenant/coordinator for the next release (described in the document), so if anyone is interested, please send me an email. I'd like this to be someone who knows enough about GIT that they will be able to manage the inflow of a mix of patches and PO files, publish a git repository somewhere (if need be, I can provide space), and allow me to merge translations from their tree when necessary (just before a release). -Dan
2008/1/8, Dan McGee <dpmcgee@gmail.com>:
On Jan 6, 2008 9:18 PM, Travis Willard <travis@archlinux.org> wrote:
On Jan 5, 2008 7:30 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Travis- I'll send you more details soon so we can get a corresponding abs package release together.
Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.
I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.
Final update of pacman-git tonight so it can be installed side-by-side with testing/abs. PLEASE report anything, otherwise source tarball release happens tomorrow.
Slight updates to the webpage too: http://www.archlinux.org/pacman/, and notably to the translation-help file. I'll be looking for a translation lieutenant/coordinator for the next release (described in the document), so if anyone is interested, please send me an email. I'd like this to be someone who knows enough about GIT that they will be able to manage the inflow of a mix of patches and PO files, publish a git repository somewhere (if need be, I can provide space), and allow me to merge translations from their tree when necessary (just before a release).
just a very small notice: since abs is not a part of Pacman anymore, this line can be removed from NEWS: - allow abs to not be included (FS#7319) -- Roman Kyrylych (Роман Кирилич)
On Jan 8, 2008 9:15 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2008/1/8, Dan McGee <dpmcgee@gmail.com>:
On Jan 6, 2008 9:18 PM, Travis Willard <travis@archlinux.org> wrote:
On Jan 5, 2008 7:30 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Travis- I'll send you more details soon so we can get a corresponding abs package release together.
Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.
I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.
Final update of pacman-git tonight so it can be installed side-by-side with testing/abs. PLEASE report anything, otherwise source tarball release happens tomorrow.
Slight updates to the webpage too: http://www.archlinux.org/pacman/, and notably to the translation-help file. I'll be looking for a translation lieutenant/coordinator for the next release (described in the document), so if anyone is interested, please send me an email. I'd like this to be someone who knows enough about GIT that they will be able to manage the inflow of a mix of patches and PO files, publish a git repository somewhere (if need be, I can provide space), and allow me to merge translations from their tree when necessary (just before a release).
just a very small notice: since abs is not a part of Pacman anymore, this line can be removed from NEWS: - allow abs to not be included (FS#7319)
Good call. I'll change it to "ABS removed from pacman package" or something. Any other NEWS updates while we are at it? Speak up today, please. -Dan
2008/1/8, Dan McGee <dpmcgee@gmail.com>:
Good call. I'll change it to "ABS removed from pacman package" or something.
Any other NEWS updates while we are at it? Speak up today, please.
I've read all additions completely and they are fine to me. No missing important things comes to my mind now, I guess everything other is OK. (in case we really missed some change that deserves to be mentioned - someone will notice this after 3.1 release and it can be added in 3.1 section when releasing 3.1.1) -- Roman Kyrylych (Роман Кирилич)
Good call. I'll change it to "ABS removed from pacman package" or something.
Any other NEWS updates while we are at it? Speak up today, please.
-Dan
http://www.archlinux.org/pipermail/pacman-dev/2007-December/010585.html Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Jan 8, 2008 10:45 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Good call. I'll change it to "ABS removed from pacman package" or something.
Any other NEWS updates while we are at it? Speak up today, please.
-Dan
http://www.archlinux.org/pipermail/pacman-dev/2007-December/010585.html
Um, the point 1 there says "we implemented new features"... isn't that what we're trying to assess? WHICH new features?
Idézés Aaron Griffin <aaronmgriffin@gmail.com>:
On Jan 8, 2008 10:45 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Good call. I'll change it to "ABS removed from pacman package" or
something.
Any other NEWS updates while we are at it? Speak up today, please.
-Dan
http://www.archlinux.org/pipermail/pacman-dev/2007-December/010585.html
Um, the point 1 there says "we implemented new features"... isn't that what we're trying to assess? WHICH new features?
Maybe I was wrong, and only one, I dunno. I referred here to the fact that we did some git commits after the last NEWS modification. But I cannot say more than 'git log' ;-) [I mentioned "my" new feature, and a hidden new feature.] Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
Signed-off-by: Chantry Xavier <shiningxc@gmail.com> --- NEWS | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index 350aece..3b207a2 100644 --- a/NEWS +++ b/NEWS @@ -31,6 +31,8 @@ VERSION DESCRIPTION - optdepends support - delta support - versioned provisions support + - versioned conflicts support + - add < and > operators for versioned dependencies and conflicts - bash completion updates - mirrorlist updates - allow multiple pacman cache directories -- 1.5.4.rc2
Good call. I'll change it to "ABS removed from pacman package" or something.
Any other NEWS updates while we are at it? Speak up today, please.
-Dan
1. I did a quick compare between _parseconfig and pacman.conf manual, I found the following undocumented keys: -ILoveCandy (what's this ?;-) -UseColor -UpgradeDelay 2. Some notes for pacman manual: -S documentation is not complete (groups!, providers) -R group is also missing Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Jan 8, 2008 10:55 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Good call. I'll change it to "ABS removed from pacman package" or something.
Any other NEWS updates while we are at it? Speak up today, please.
-Dan
1. I did a quick compare between _parseconfig and pacman.conf manual, I found the following undocumented keys: -ILoveCandy (what's this ?;-) -UseColor -UpgradeDelay
Anyone is free to write documentation, I feel like I've about done my share...
2. Some notes for pacman manual: -S documentation is not complete (groups!, providers) -R group is also missing
Same as above... Even if it isn't perfect English, it saves me time. Just write it to the style of already-documented options, I'll fix up the grammar. -Dan
Idézés Dan McGee <dpmcgee@gmail.com>:
On Jan 8, 2008 10:55 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Good call. I'll change it to "ABS removed from pacman package" or
something.
Any other NEWS updates while we are at it? Speak up today, please.
-Dan
1. I did a quick compare between _parseconfig and pacman.conf manual, I found the following undocumented keys: -ILoveCandy (what's this ?;-) -UseColor -UpgradeDelay
Anyone is free to write documentation, I feel like I've about done my share...
2. Some notes for pacman manual: -S documentation is not complete (groups!, providers) -R group is also missing
Same as above...
Even if it isn't perfect English, it saves me time. Just write it to the style of already-documented options, I'll fix up the grammar.
Sorry, I cannot do this today (<- I announce this to avoid waiting for me -- pacman is released soon), because I'm writing from a windows terminal of a library... Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Tue, Jan 08, 2008 at 05:55:30PM +0100, Nagy Gabor wrote:
1. I did a quick compare between _parseconfig and pacman.conf manual, I found the following undocumented keys: -ILoveCandy (what's this ?;-)
It is a little easter egg. I don't think there is any need to document it.
-UseColor
Currently doesn't do anything; no need to document it either.
-UpgradeDelay
Never noticed that one before, had to look through the code to see what it did. It's actually a pretty neat feature.
2. Some notes for pacman manual: -S documentation is not complete (groups!, providers) -R group is also missing
I'll try to add these plus the UpgradeDelay within the hour.
On Jan 8, 2008 11:48 AM, Nathan Jones <nathanj@insightbb.com> wrote:
On Tue, Jan 08, 2008 at 05:55:30PM +0100, Nagy Gabor wrote:
1. I did a quick compare between _parseconfig and pacman.conf manual, I found
-UseColor
Currently doesn't do anything; no need to document it either.
-UpgradeDelay
Never noticed that one before, had to look through the code to see what it did. It's actually a pretty neat feature.
Not sure if this actually works, thats my only concern. I've never tested it.
2. Some notes for pacman manual: -S documentation is not complete (groups!, providers) -R group is also missing
I'll try to add these plus the UpgradeDelay within the hour.
Thanks a bunch. Release in about 12 hours more than likely so you have plenty of time. :) -Dan
On Tue, Jan 08, 2008 at 12:04:40PM -0600, Dan McGee wrote:
On Jan 8, 2008 11:48 AM, Nathan Jones <nathanj@insightbb.com> wrote:
On Tue, Jan 08, 2008 at 05:55:30PM +0100, Nagy Gabor wrote:
1. I did a quick compare between _parseconfig and pacman.conf manual, I found
-UseColor
Currently doesn't do anything; no need to document it either.
-UpgradeDelay
Never noticed that one before, had to look through the code to see what it did. It's actually a pretty neat feature.
Not sure if this actually works, thats my only concern. I've never tested it.
Looks like it doesn't work :) The problem seems to be that pkg->date is never set anywhere (this is actually the only function that references it). I think changing it to pkg->builddate will work. int _alpm_pkg_istoonew(pmpkg_t *pkg) { time_t t; ALPM_LOG_FUNC; if (!handle->upgradedelay) return 0; time(&t); return((pkg->date + handle->upgradedelay) > t); }
Nathan Jones wrote:
Looks like it doesn't work :) The problem seems to be that pkg->date is never set anywhere (this is actually the only function that references it). I think changing it to pkg->builddate will work.
int _alpm_pkg_istoonew(pmpkg_t *pkg) { time_t t;
ALPM_LOG_FUNC;
if (!handle->upgradedelay) return 0; time(&t); return((pkg->date + handle->upgradedelay)> t); }
That's a funny feature indeed. People who always complain about stability could get upgrades always a few days later so that other people test them first :) Indeed, pkg->date isn't set and used anywhere. It could probably be removed. builddate is set, but it isn't in the sync db, so it wouldn't work either. But the only way for this feature to work would be to add the builddate to the db, right? Hmm, now that I'm thinking about it, I'm not sure build date is the correct value. Shouldn't it rather be the date when the package is moved to the stable repos rather? (I'm thinking about packages that stay a period in testing first, and never the same delay). But more generally, just the date when the package is added to the repo would do.
On Jan 8, 2008 1:48 PM, Xavier <shiningxc@gmail.com> wrote:
Nathan Jones wrote:
Looks like it doesn't work :) The problem seems to be that pkg->date is never set anywhere (this is actually the only function that references it). I think changing it to pkg->builddate will work.
int _alpm_pkg_istoonew(pmpkg_t *pkg) { time_t t;
ALPM_LOG_FUNC;
if (!handle->upgradedelay) return 0; time(&t); return((pkg->date + handle->upgradedelay)> t); }
That's a funny feature indeed. People who always complain about stability could get upgrades always a few days later so that other people test them first :)
Indeed, pkg->date isn't set and used anywhere. It could probably be removed. builddate is set, but it isn't in the sync db, so it wouldn't work either. But the only way for this feature to work would be to add the builddate to the db, right?
Hmm, now that I'm thinking about it, I'm not sure build date is the correct value. Shouldn't it rather be the date when the package is moved to the stable repos rather? (I'm thinking about packages that stay a period in testing first, and never the same delay). But more generally, just the date when the package is added to the repo would do.
This seems like a feature introduced to solve a problem the wrong way. If people didn't release broken packages, this really wouldn't be necessary. Any reason not to just kill it completely? -Dan
Dan McGee wrote:
This seems like a feature introduced to solve a problem the wrong way. If people didn't release broken packages, this really wouldn't be necessary.
Any reason not to just kill it completely?
No, as Nathan said, it's broken. And I think it's not possible to fix it with the current sync dbs, so we might as well remove it. And the implementation is rather simple anyway.
On Tue, Jan 08, 2008 at 09:16:52PM +0100, Xavier wrote:
Dan McGee wrote:
This seems like a feature introduced to solve a problem the wrong way. If people didn't release broken packages, this really wouldn't be necessary.
Any reason not to just kill it completely?
No, as Nathan said, it's broken. And I think it's not possible to fix it with the current sync dbs, so we might as well remove it. And the implementation is rather simple anyway.
My test repo and community has the BUILDDATE field in it, but core and extra do not. I have a patch that works for simple cases, but I'm sure it fails for versioned dependencies. I've included the patch if anyone wants to mess with it. I'm fine with removing it. From: Nathan Jones <nathanj@insightbb.com> Date: Tue, 8 Jan 2008 14:14:05 -0500 Subject: [PATCH] Make UpdateDelay work. Previously, _alpm_pkg_istoonew was using pmpkg_t.date for comparing dates, but that variable was never being set. Change it to use pmpkg_t.builddate instead. Remove pmpkg_t.date since it is not used. Change alpm_pkg_compare_versions to return a 2 when the package is not supposed to be upgraded due to UpgradeDelay so that the sync functions can know not to include that package. Signed-off-by: Nathan Jones <nathanj@insightbb.com> --- lib/libalpm/package.c | 16 ++++++++++++---- lib/libalpm/package.h | 1 - lib/libalpm/sync.c | 8 ++++++-- 3 files changed, 18 insertions(+), 7 deletions(-) diff --git a/lib/libalpm/package.c b/lib/libalpm/package.c index 657de7d..ff03be0 100644 --- a/lib/libalpm/package.c +++ b/lib/libalpm/package.c @@ -824,7 +824,13 @@ void _alpm_pkg_free(pmpkg_t *pkg) FREE(pkg); } -/* Is pkgB an upgrade for pkgA ? */ +/* Is pkg an upgrade for local_pkg ? + * + * returns: + * 0 - new package is older than local + * 1 - new package is newer + * 2 - new package is newer but is not yet past UpgradeDelay time + */ int alpm_pkg_compare_versions(pmpkg_t *local_pkg, pmpkg_t *pkg) { int cmp = 0; @@ -851,13 +857,14 @@ int alpm_pkg_compare_versions(pmpkg_t *local_pkg, pmpkg_t *pkg) alpm_db_get_name(db), alpm_pkg_get_version(pkg)); cmp = 0; } else if(cmp > 0) { + cmp = 1; /* we have an upgrade, make sure we should actually do it */ if(_alpm_pkg_istoonew(pkg)) { /* package too new (UpgradeDelay) */ _alpm_log(PM_LOG_WARNING, _("%s-%s: delaying upgrade of package (%s)\n"), alpm_pkg_get_name(local_pkg), alpm_pkg_get_version(local_pkg), alpm_pkg_get_version(pkg)); - cmp = 0; + cmp = 2; } } @@ -1157,10 +1164,11 @@ int _alpm_pkg_istoonew(pmpkg_t *pkg) ALPM_LOG_FUNC; - if (!handle->upgradedelay) + if (!handle->upgradedelay) { return 0; + } time(&t); - return((pkg->date + handle->upgradedelay) > t); + return((pkg->builddate + handle->upgradedelay) > t); } /** Test if a package should be ignored. diff --git a/lib/libalpm/package.h b/lib/libalpm/package.h index 7ef41f9..f818ae2 100644 --- a/lib/libalpm/package.h +++ b/lib/libalpm/package.h @@ -61,7 +61,6 @@ struct __pmpkg_t { unsigned long isize; unsigned short scriptlet; unsigned short force; - time_t date; pmpkgreason_t reason; alpm_list_t *licenses; alpm_list_t *replaces; diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c index ec4af9f..0b3b411 100644 --- a/lib/libalpm/sync.c +++ b/lib/libalpm/sync.c @@ -238,7 +238,7 @@ int _alpm_sync_sysupgrade(pmtrans_t *trans, } /* compare versions and see if we need to upgrade */ - if(alpm_pkg_compare_versions(local, spkg)) { + if(alpm_pkg_compare_versions(local, spkg) == 1) { _alpm_log(PM_LOG_DEBUG, "%s elected for upgrade (%s => %s)\n", alpm_pkg_get_name(local), alpm_pkg_get_version(local), alpm_pkg_get_version(spkg)); @@ -354,7 +354,8 @@ int _alpm_sync_addtarget(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sy local = _alpm_db_get_pkgfromcache(db_local, alpm_pkg_get_name(spkg)); if(local) { - if(alpm_pkg_compare_versions(local, spkg) == 0) { + int cmp = alpm_pkg_compare_versions(local, spkg); + if(cmp == 0) { /* spkg is NOT an upgrade */ if(trans->flags & PM_TRANS_FLAG_NEEDED) { _alpm_log(PM_LOG_WARNING, _("%s-%s is up to date -- skipping\n"), @@ -364,6 +365,9 @@ int _alpm_sync_addtarget(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sy _alpm_log(PM_LOG_WARNING, _("%s-%s is up to date -- reinstalling\n"), alpm_pkg_get_name(local), alpm_pkg_get_version(local)); } + } else if (cmp == 2) { + /* not upgrading (UpgradeDelay) */ + return(0); } } -- 1.5.3.7
Nathan Jones wrote:
On Tue, Jan 08, 2008 at 09:16:52PM +0100, Xavier wrote:
Dan McGee wrote:
This seems like a feature introduced to solve a problem the wrong way. If people didn't release broken packages, this really wouldn't be necessary.
Any reason not to just kill it completely?
No, as Nathan said, it's broken. And I think it's not possible to fix it with the current sync dbs, so we might as well remove it. And the implementation is rather simple anyway.
My test repo and community has the BUILDDATE field in it, but core and extra do not.
Oops, yes you're right, I'm just blind. I just saw it wasn't there in core / extra. Then I checked the repo-add script, and I didn't find the BUILDDATE field... But yes, it's there indeed. And community does have that field. So it works alright with community repo (after the date -> builddate change). But anyway, I think I agree with Dan finally, this feature might be a bit wrong.
On Tue, Jan 08, 2008 at 02:13:53PM -0600, Dan McGee wrote:
On Jan 8, 2008 1:48 PM, Xavier <shiningxc@gmail.com> wrote:
Nathan Jones wrote:
Looks like it doesn't work :) The problem seems to be that pkg->date is never set anywhere (this is actually the only function that references it). I think changing it to pkg->builddate will work.
int _alpm_pkg_istoonew(pmpkg_t *pkg) { time_t t;
ALPM_LOG_FUNC;
if (!handle->upgradedelay) return 0; time(&t); return((pkg->date + handle->upgradedelay)> t); }
That's a funny feature indeed. People who always complain about stability could get upgrades always a few days later so that other people test them first :)
Indeed, pkg->date isn't set and used anywhere. It could probably be removed. builddate is set, but it isn't in the sync db, so it wouldn't work either. But the only way for this feature to work would be to add the builddate to the db, right?
Hmm, now that I'm thinking about it, I'm not sure build date is the correct value. Shouldn't it rather be the date when the package is moved to the stable repos rather? (I'm thinking about packages that stay a period in testing first, and never the same delay). But more generally, just the date when the package is added to the repo would do.
This seems like a feature introduced to solve a problem the wrong way. If people didn't release broken packages, this really wouldn't be necessary.
Any reason not to just kill it completely?
-Dan
If I recall correctly it came into being after I talked with Judd or Aaron... I didn't think it was really necessary, but it was a stop gap between having a stable/better tested repo and what we had before Aaron came in with the testing policy (which hasn't been a silver bullet). I think it's probably too late to weigh in on whether it should stay or not, but this is where it came from. I'm nothing if not a living history of Arch Linux development ;) Jason
On 1/10/08, Jason Chu <jason@archlinux.org> wrote:
On Tue, Jan 08, 2008 at 02:13:53PM -0600, Dan McGee wrote:
On Jan 8, 2008 1:48 PM, Xavier <shiningxc@gmail.com> wrote:
Nathan Jones wrote:
Looks like it doesn't work :) The problem seems to be that pkg->date is never set anywhere (this is actually the only function that references it). I think changing it to pkg->builddate will work.
int _alpm_pkg_istoonew(pmpkg_t *pkg) { time_t t;
ALPM_LOG_FUNC;
if (!handle->upgradedelay) return 0; time(&t); return((pkg->date + handle->upgradedelay)> t); }
That's a funny feature indeed. People who always complain about stability could get upgrades always a few days later so that other people test them first :)
Indeed, pkg->date isn't set and used anywhere. It could probably be removed. builddate is set, but it isn't in the sync db, so it wouldn't work either. But the only way for this feature to work would be to add the builddate to the db, right?
Hmm, now that I'm thinking about it, I'm not sure build date is the correct value. Shouldn't it rather be the date when the package is moved to the stable repos rather? (I'm thinking about packages that stay a period in testing first, and never the same delay). But more generally, just the date when the package is added to the repo would do.
This seems like a feature introduced to solve a problem the wrong way. If people didn't release broken packages, this really wouldn't be necessary.
Any reason not to just kill it completely?
-Dan
If I recall correctly it came into being after I talked with Judd or Aaron...
I didn't think it was really necessary, but it was a stop gap between having a stable/better tested repo and what we had before Aaron came in with the testing policy (which hasn't been a silver bullet).
I think it's probably too late to weigh in on whether it should stay or not, but this is where it came from. I'm nothing if not a living history of Arch Linux development ;)
Just so long as you don't turn into Eric Raymond.... ;)
Document the following: * -R can take a group * -S can take a group and provision I also split up the -S description into multiple paragraphs because it was getting too large. Signed-off-by: Nathan Jones <nathanj@insightbb.com> --- doc/pacman.8.txt | 25 +++++++++++++++++++------ 1 files changed, 19 insertions(+), 6 deletions(-) diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 99133dd..a106c94 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -43,10 +43,12 @@ Operations individual '.tar.gz' packages. See <<QO,Query Options>> below. *-R, \--remove*:: - Remove a package from the system. Files belonging to the specified - package will be deleted, and the database will be updated. Most - configuration files will be saved with a `.pacsave` extension unless the - '\--nosave' option is used. See <<RO,Remove Options>> below. + Remove a package from the system. Groups can also be specified to be + removed, in which case every package in that group will be removed. + Files belonging to the specified package will be deleted, and the + database will be updated. Most configuration files will be saved + with a `.pacsave` extension unless the '\--nosave' option is used. + See <<RO,Remove Options>> below. *-S, \--sync*:: Synchronize packages. Packages are installed directly from the ftp @@ -54,8 +56,19 @@ Operations example, `pacman -S qt` will download and install qt and all the packages it depends on. If a package name exists in more than one repo, the repo can be explicitly specified to clarify the package to install: - `pacman -S testing/qt`. You can also use `pacman -Su` to upgrade all - packages that are out of date. See <<SO,Sync Options>> below. + `pacman -S testing/qt`. ++ +In addition to packages, groups can be specified as well. For +example, `pacman -S gnome` will install every package in the gnome +group, as well as the dependencies of those packages. ++ +Packages which provide other packages are also handled. For example, +`pacman -S foo` will first look for a foo package. If foo is not found, +packages which provide the same functionality as foo will be searched +for. If any package is found, it will be installed. ++ +You can also use `pacman -Su` to upgrade all packages that are out +of date. See <<SO,Sync Options>> below. *-U, \--upgrade*:: Upgrade or add a package to the system. Either a URL or file path can be -- 1.5.3.7
Nathan Jones wrote:
Document the following:
* -R can take a group * -S can take a group and provision
I also split up the -S description into multiple paragraphs because it was getting too large.
Signed-off-by: Nathan Jones <nathanj@insightbb.com> --- doc/pacman.8.txt | 25 +++++++++++++++++++------ 1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 99133dd..a106c94 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -43,10 +43,12 @@ Operations individual '.tar.gz' packages. See <<QO,Query Options>> below.
*-R, \--remove*:: - Remove a package from the system. Files belonging to the specified - package will be deleted, and the database will be updated. Most - configuration files will be saved with a `.pacsave` extension unless the - '\--nosave' option is used. See <<RO,Remove Options>> below. + Remove a package from the system. Groups can also be specified to be + removed, in which case every package in that group will be removed. + Files belonging to the specified package will be deleted, and the + database will be updated. Most configuration files will be saved + with a `.pacsave` extension unless the '\--nosave' option is used. + See <<RO,Remove Options>> below.
*-S, \--sync*:: Synchronize packages. Packages are installed directly from the ftp @@ -54,8 +56,19 @@ Operations example, `pacman -S qt` will download and install qt and all the packages it depends on. If a package name exists in more than one repo, the repo can be explicitly specified to clarify the package to install: - `pacman -S testing/qt`. You can also use `pacman -Su` to upgrade all - packages that are out of date. See <<SO,Sync Options>> below. + `pacman -S testing/qt`. ++ +In addition to packages, groups can be specified as well. For +example, `pacman -S gnome` will install every package in the gnome +group, as well as the dependencies of those packages.
Minor point, but since pacman has moved to being distribution agnostic, do we want to mention specific package names or stick to "foo"? This would look strange on a distro that didn't provide GNOME.
++ +Packages which provide other packages are also handled. For example, +`pacman -S foo` will first look for a foo package. If foo is not found, +packages which provide the same functionality as foo will be searched +for. If any package is found, it will be installed. ++ +You can also use `pacman -Su` to upgrade all packages that are out +of date. See <<SO,Sync Options>> below.
*-U, \--upgrade*:: Upgrade or add a package to the system. Either a URL or file path can be
On Jan 8, 2008 3:21 PM, Allan McRae <mcrae_allan@hotmail.com> wrote:
Nathan Jones wrote:
++ +In addition to packages, groups can be specified as well. For +example, `pacman -S gnome` will install every package in the gnome +group, as well as the dependencies of those packages.
Minor point, but since pacman has moved to being distribution agnostic, do we want to mention specific package names or stick to "foo"? This would look strange on a distro that didn't provide GNOME.
Valid point though, although I think real package names help people out. "For example, if gnome is a defined package group, pacman -S gnome will..." sound ok?
Dan McGee wrote:
On Jan 8, 2008 3:21 PM, Allan McRae <mcrae_allan@hotmail.com> wrote:
Nathan Jones wrote:
++ +In addition to packages, groups can be specified as well. For +example, `pacman -S gnome` will install every package in the gnome +group, as well as the dependencies of those packages.
Minor point, but since pacman has moved to being distribution agnostic, do we want to mention specific package names or stick to "foo"? This would look strange on a distro that didn't provide GNOME.
Valid point though, although I think real package names help people out.
"For example, if gnome is a defined package group, pacman -S gnome will..."
sound ok? Yes. That is probably a better way to get around the issue.
participants (11)
-
Aaron Griffin
-
Allan McRae
-
Chantry Xavier
-
Dan McGee
-
eliott
-
Jason Chu
-
Nagy Gabor
-
Nathan Jones
-
Roman Kyrylych
-
Travis Willard
-
Xavier