FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 01-08-2008, 05:04 PM
"Dan McGee"
 
Default Some undocumented things

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

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 01-08-2008, 06:09 PM
Nathan Jones
 
Default Some undocumented things

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);
}

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 01-08-2008, 06:48 PM
Xavier
 
Default Some undocumented things

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.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 01-08-2008, 07:13 PM
"Dan McGee"
 
Default Some undocumented things

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

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 01-08-2008, 07:16 PM
Xavier
 
Default Some undocumented things

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.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 01-08-2008, 07:25 PM
Nathan Jones
 
Default Some undocumented things

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)
"),
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)
",
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
"),
@@ -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
"),
alpm_pkg_get_name(local), alpm_pkg_get_version(local));
}
+ } else if (cmp == 2) {
+ /* not upgrading (UpgradeDelay) */
+ return(0);
}
}

--
1.5.3.7

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 01-08-2008, 09:05 PM
Xavier
 
Default Some undocumented things

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.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 01-10-2008, 10:56 PM
Jason Chu
 
Default Some undocumented things

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
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 01-10-2008, 11:07 PM
eliott
 
Default Some undocumented things

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....


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 

Thread Tools




All times are GMT. The time now is 04:19 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org