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 02-06-2008, 02:02 AM
"Dan McGee"
 
Default Pacman TODO from Xavier

Xavier pointed out a few pending items to me with pacman, and I
thought I'd respond to his list here on the ML. Thoughts welcome from
anyone else.

> * -Qo and symlink :
> http://www.archlinux.org/pipermail/pacman-dev/2008-February/011061.html
> http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=commit;h=cd43c63f99df1cf 5e90cb556fa289a6de310a4c8

Merged into maint tonight.

> * pacman.conf clean up :
> http://www.archlinux.org/pipermail/pacman-dev/2008-January/010996.html

Replied to this message on the ML.

> * ChangeLog.proto :
> http://archlinux.org/pipermail/arch-dev-public/2008-January/004020.html
> http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=commitdiff;h=66e1f725cbc efe126e23b6de026b19ae3250399b

Merged.

> * install contrib files
> http://www.archlinux.org/pipermail/pacman-dev/2008-January/010782.html

How about an AUR package? pacman-contrib? Someone might even maintain
it in community.

> * ignore targets not found :
> point 2) there :
> http://www.archlinux.org/pipermail/pacman-dev/2007-September/009412.html

3.2 issue for sure. Interesting, but I like programs to fail hard with
invalid input rather than gloss it over. When you script programs, it
can be very misleading if things don't fail when you expect them to.

> * broken database with two duplicated entries :
> for example :
> var/lib/pacman/local/xorg-xauth-1.0.1-1/
> var/lib/pacman/local/xorg-xauth-1.0.2-1/
>
> If we want to do this check in testdb, don't we need db_splitname or something?
> If we do it in libalpm, where exactly?

I punted this one to Xavier because I didn't exactly know how to do it.

Can't we just load the entire local pkgcache and then scan for
duplicate names? I was originally thinking of doing this outside of
libalpm, and at some point we can add some consistency checks into the
library if necessary that ensure no pkgname is duplicated inside a
single repo.

> * segfault : FS#9235
>
> * memleak caused by 8240da6cb3ff95ad480efe3e1876104024398fae
> how to track whether a package has been added to the pkgcache or not.
> The target list is currently never freed. only the pkgcache is.
> If a package from the target list hasn't been added to the cache (because of a
> failure, conflict or whatever), it won't be freed.

Xavier- if you could bring this up in a separate email thread, that
would probably be best. This is an issue where people are just going
to have to sit down and try and work out a system for being sure of
when/where a package needs to be freed.

> * -Ru (unneeded) branch
> http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=unneeded

Mostly because I just haven't merged it yet. I'll try to get a good
look at this soon and see if it is good to go for master.

> * xdelta support
> maybe we need a mail about the status on this, what needs to be done:
> http://bbs.archlinux.org/viewtopic.php?id=43426
> (waiting on Nathan)

xdelta support in repo-add would probably be our next step- we may
need to refactor the common code out of repo-add and makepkg into some
kind of makepkg lib, which I am not completely sure how to address.

> * upgrade refactoring
> status mail on this too?

What does this refer to? The idea of our add/remove package lists? If
so, it is still an idea brewing in a lot of our heads but no one has
made any huge advances on it yet. Of course, it is not going to me an
easy or clean change either.

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 02-06-2008, 02:40 AM
Allan McRae
 
Default Pacman TODO from Xavier

Dan McGee wrote:
>> * install contrib files
>> http://www.archlinux.org/pipermail/pacman-dev/2008-January/010782.html
>>
>
> How about an AUR package? pacman-contrib? Someone might even maintain
> it in community.
>
I like the idea of these in a separate package as it keeps them in a
semi-official status and they won't directly hold up a pacman release if
some future change means these need updated.

I will volunteer to maintain these in a package in the community repos.

Allan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 02-06-2008, 09:06 AM
Xavier
 
Default Pacman TODO from Xavier

On Feb 6, 2008 4:02 AM, Dan McGee <dpmcgee@gmail.com> wrote:
> > * upgrade refactoring
> > status mail on this too?
>
> What does this refer to? The idea of our add/remove package lists? If
> so, it is still an idea brewing in a lot of our heads but no one has
> made any huge advances on it yet. Of course, it is not going to me an
> easy or clean change either.
>

Well, you mentioned to me you might be able to reformulate the current
ideas that you and Aaron had, so that it could be shared and discussed
here Obviously, this is low priority, so no hurry.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 02-06-2008, 12:38 PM
Nagy Gabor
 
Default Pacman TODO from Xavier

> > * memleak caused by 8240da6cb3ff95ad480efe3e1876104024398fae
> > how to track whether a package has been added to the pkgcache or not.
> > The target list is currently never freed. only the pkgcache is.
> > If a package from the target list hasn't been added to the cache (because
> of a
> > failure, conflict or whatever), it won't be freed.
>
> Xavier- if you could bring this up in a separate email thread, that
> would probably be best. This is an issue where people are just going
> to have to sit down and try and work out a system for being sure of
> when/where a package needs to be freed.

Well, IMHO we shouldn't release 3.1.2 while this is not fixed.
To be honest, I find the old way more straightforward (~= closer to human
thinking => probably less buggy); and I'm not sure this small memory cut worth
this "hackish" fix.
So I suggest reverting 8240da6cb3, and may implement it in the
'reduced-memory-usage 3.2' (dynamic strings etc.) if you still find it useful.

> > * -Ru (unneeded) branch
> >
> http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=unneeded
>
> Mostly because I just haven't merged it yet. I'll try to get a good
> look at this soon and see if it is good to go for master.
>

Well, I repeat my warning
(http://www.archlinux.org/pipermail/pacman-dev/2007-December/010377.html -- 2.
is not valid now):
After "requiredby killing" both -Rc and -Ru became much more slower, because
they may call checkdeps many times (in case of certain long dependency paths)
and checkdeps _computes_ the requiredby fields implicitly in each call.
The issue is similar to this:
http://www.archlinux.org/pipermail/pacman-dev/2007-November/010339.html

I made some tests with -Rc on my machine (1400 MHz AthlonXP) and in 'real' cases
(<100 dependency) the problem didn't appear.

Bye

----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 02-06-2008, 01:30 PM
Xavier
 
Default Pacman TODO from Xavier

Nagy Gabor wrote:
>>> * memleak caused by 8240da6cb3ff95ad480efe3e1876104024398fae
>>> how to track whether a package has been added to the pkgcache or not.
>>> The target list is currently never freed. only the pkgcache is.
>>> If a package from the target list hasn't been added to the cache (because
>> of a
>>> failure, conflict or whatever), it won't be freed.
>> Xavier- if you could bring this up in a separate email thread, that
>> would probably be best. This is an issue where people are just going
>> to have to sit down and try and work out a system for being sure of
>> when/where a package needs to be freed.
>
> Well, IMHO we shouldn't release 3.1.2 while this is not fixed.
> To be honest, I find the old way more straightforward (~= closer to human
> thinking => probably less buggy); and I'm not sure this small memory cut worth
> this "hackish" fix.
> So I suggest reverting 8240da6cb3, and may implement it in the
> 'reduced-memory-usage 3.2' (dynamic strings etc.) if you still find it useful.

That's already the way it is.
All this memory stuff only went to master, for the 3.2 release, so that
we get the time to test and fix things. As opposed to the maint branch,
for the 3.1.x bugfix releases.

And if you consider a big transaction (for example, installing the base
group or even whole core repo, or whole kde group), duplicating every
pkg in the mem should make a difference.

>
>>> * -Ru (unneeded) branch
>>>
>> http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=unneeded
>>
>> Mostly because I just haven't merged it yet. I'll try to get a good
>> look at this soon and see if it is good to go for master.
>>
>
> Well, I repeat my warning
> (http://www.archlinux.org/pipermail/pacman-dev/2007-December/010377.html -- 2.
> is not valid now):
> After "requiredby killing" both -Rc and -Ru became much more slower, because
> they may call checkdeps many times (in case of certain long dependency paths)
> and checkdeps _computes_ the requiredby fields implicitly in each call.
> The issue is similar to this:
> http://www.archlinux.org/pipermail/pacman-dev/2007-November/010339.html
>
> I made some tests with -Rc on my machine (1400 MHz AthlonXP) and in 'real' cases
> (<100 dependency) the problem didn't appear.
>

Same here, if Dan merges this patch, it will be in master.
If you look at the current changes for 3.1.2, you will see it's mostly
about fixing existing issues, not changing the way libalpm and pacman
work internally, and not about adding or removing features.

So don't worry, you will have the time to make this little performance
improvement for 3.2
And well you said yourself it's not noticeable in real cases, so it's
not a big problem even if we don't do anything about it.

_______________________________________________
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 01:17 PM.

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