A suggestion for handling optdepends.

Dieter@be · 2010-08-01 09:21:30

Xyne wrote:

Fsck, I had written an extensive reply but my login timed out and I lost it when I hit the back button. Oh well, take 2...

/proc/kcore is your friend

Xyne wrote:

Nope, that's not how my idea would work. Allan has inverted the tracking. My idea lets packages track their own optdepends. (...)

This sounds very similar to my idea. And you still need to manually specify "I want to store (ie) tk as optdep for python" for all the logic to work correctly. Remember, we were not talking about the optdep metadata itself, but rather tracking of "why do i want this package on my system" (for real deps this is obvious, for optional deps the user needs to specify them, both with your my approach)

Xyne wrote:

* Any package could be made an optdep of any other package. The optdeps in the sync database would remain suggestions in that regard. They would nevertheless be used to create a dialogue similar to the group dialogue, as described in the OP. This dialogue could be invoke via e.g. "pacman -S --optdeps foo". Beyond that, pacman could also display a message when an optdep is removed from the sync database if it is detected as a user-defined optdep, e.g. "bar is no longer listed as an optdep for foo".

interesting

Xyne wrote:

* Groups could be replaced by metapackages with optdeps. As mentioned in the previous note, it would be possible to bring up a dialogue identical to the current group dialogue so there would be no difference in installation. The benefit would be that groups could be updated (e.g. the KDE metapackage could change its optdepend list and the user would then be informed about it on the next upgrade, with the option to resync his optdeps to the current sync db optdeps). Users could also easily define their own metapackages for e.g. system backup and migration, organization (e.g. all games in one metapackage, all office apps in another).

interesting

Xyne · 2010-08-01 09:54:08

Dieter@be wrote:

Xyne wrote:
Fsck, I had written an extensive reply but my login timed out and I lost it when I hit the back button. Oh well, take 2...
/proc/kcore is your friend

*makes mental note to investigate /proc/kcore and develop alleged friendship further*

Dieter@be wrote:

This sounds very similar to my idea. And you still need to manually specify "I want to store (ie) tk as optdep for python" for all the logic to work correctly. Remember, we were not talking about the optdep metadata itself, but rather tracking of "why do i want this package on my system" (for real deps this is obvious, for optional deps the user needs to specify them, both with your my approach)

Well, with my approach "pacman -Qi $pkgname" would include a field beneath "Required By" named e.g. "Optionally Required By", which lists the packages that currently have $pkgname set as an optdep.

I clarified the metadata handling because it should show that optdeps would behave as real deps for all practical purposes, including knowing why something is on your system.

For the sake of this discussion it might be easier to refer to sync db deps as "hard deps" and user-defined optdeps as "soft deps".

Last edited by Xyne (2010-08-01 09:56:35)

Allan · 2010-08-01 11:16:10

I suggest you take this to pacman-dev for further discussion (if you want it included in pacman...)

But be prepared for the response. As I said earlier, that is the way dependencies used to be handled (i.e. each package has a list of what it was a dependency for). Then that became an absolute nightmare to maintain so it was dropped in favour of calculating this list on the fly. So you are proposing to implement something very similar to what has already been rejected from pacman. This is why my suggestion tries to keep optdepends handling as similar to the current dependency handling as possible.

Xyne · 2010-08-01 12:04:50

Allan wrote:

I suggest you take this to pacman-dev for further discussion (if you want it included in pacman...)

I didn't revive this thread. I'm just responding to it. I will eventually implement this myself one way or another. I have other pet projects to work on in the meantime.

Allan wrote:

But be prepared for the response. As I said earlier, that is the way dependencies used to be handled (i.e. each package has a list of what it was a dependency for). Then that became an absolute nightmare to maintain so it was dropped in favour of calculating this list on the fly. So you are proposing to implement something very similar to what has already been rejected from pacman. This is why my suggestion tries to keep optdepends handling as similar to the current dependency handling as possible.

THAT IS NOT WHAT IT DOES! IT HANDLES DEPENDENCIES EXACTLY THE SAME WAY AS THE CURRENT SYSTEM!

Xyne wrote:

Dieter@be wrote:
Allan wrote:
So say I install python and then tk as an optdepends. Then I install another package which requires tk as an optdepend. If I want to use tk as an optdep for both packages, I need to run some command to manually add foo to the optdepends required by list for tk?
hmm, with my approach (and I think Xyne's also), that would indeed be the case.
Nope, that's not how my idea would work. Allan has inverted the tracking. My idea lets packages track their own optdepends.

I directly stated that it does not do that, then I gave a very clear explanation of how it would work. Read read my full reply as you obviously haven't. It's not that long and it's simple enough that even you should have a difficult time mischaracterizing it for the sake of an uninformed unilateral argument.

If you really can't be arsed to follow a discussion, don't bother interjecting your negativity into it. As much as I appreciate the vast amount of work that you do for Arch and thus indirectly for me, I really can't stand this habit of yours.

Again, note that I am not asking anyone to implement this. I see proposing ideas on the dev lists as futile anyway There is too much apathy and groupthink there for most discussions to be productive. It's a consequence of most long-term projects which have seen their fair share of bad ideas. Although I find it unfortunate, I don't actually bitch about it. I just avoid it.

Allan · 2010-08-01 13:02:04

You are asking someone to implement it. You filed a bug in the bug tracker and asked people to vote for it. That screams "hey, implement me!". Claiming otherwise is just being... um lets go for naive so I do not invoke censoring...

So given you have actually asked for this to be implemented, I was suggesting to take this to pacman-dev where the pacman development actually occurs. Currently mine is the only proposal that has been posted on the list where development occurs, and for better or worse, that is the only design document the developers of pacman have seen and commented on. Unless other proposals are shown on the development list for general comments, that will remain the one to be used when one of the few contributors to pacman implements improvements to optdep handling. Also, how is putting a description on the forums any less groupthink than the pacman-dev mailing list that is frequented by far, far less people?

And seriously... stop being a condescending arse, or at least assuming that I am being an arse. None of our previous "discussions" have shown that I misunderstood what was being posted. They just showed that I thought the previous ideas we disagreed on were really shit. Here I have shown a lack of understanding of what is proposed which is entirely different, so your reply is overly strongly worded.

For what its worth, my confusion stems from the usage of the %OPTDEPENDS% in the new database file. That heading is already used in the pacman database (in the desc file) and for it to be re-used in dependency removal calculations would require doing it the way round I had posted about. So the misunderstanding is all my fault... I should not assume people understand the database structure and how it is read in, even if that is what they are trying to improve.

litemotiv · 2010-08-01 14:26:20

Both Xyne and Allan, the behaviour you two are portraying in this thread is obviously unacceptable.

You have a week to think about more constructive ways of interacting with each other. Thread closed.

Arch Linux

#26 2010-08-01 09:21:30

Re: A suggestion for handling optdepends.

#27 2010-08-01 09:54:08

Re: A suggestion for handling optdepends.

#28 2010-08-01 11:16:10

Re: A suggestion for handling optdepends.

#29 2010-08-01 12:04:50

Re: A suggestion for handling optdepends.

#30 2010-08-01 13:02:04

Re: A suggestion for handling optdepends.

#31 2010-08-01 14:26:20

Re: A suggestion for handling optdepends.

Board footer