Multiple repos solve problems with the restricted mirrors, too So Sparky should join the team and we use his package manager!gapan wrote:Basically you can have multiple repos enabled (each one with its own PACKAGES.TXT) and if you search for a package, you search in any of them. Also if package A needs dependency B and B is in a different repo than A, then it should transparently download it anyway.
Repository package managers
Re: Repository package managers
Re: Repository package managers
Hum...seems not intuitive to me."default < official < preferred < custom"
Could the prority simply be with an order in a file ? Higher in the file, higher the prority is.
Re: Repository package managers
Yes, this ordering is shit I've wondered what's higher: default or official?JRD wrote:Hum...seems not intuitive to me."default < official < preferred < custom"
Could the prority simply be with an order in a file ? Higher in the file, higher the prority is.
Better use something straight: low - normal - high
Or: 1 - 2 - 3...
Re: Repository package managers
Agreed. Having 4 levels would be nice.thenktor wrote:Yes, this ordering is shit I've wondered what's higher: default or official?JRD wrote:Hum...seems not intuitive to me."default < official < preferred < custom"
Could the prority simply be with an order in a file ? Higher in the file, higher the prority is.
Better use something straight: low - normal - high
Or: 1 - 2 - 3...
Re: Repository package managers
So, just to be clear before I begin design planning, it should support up to 4 mirrors at a time, each with a different priority? Priorities might be better as words, instead of numbers, so that users aren't confused about when 1 is high or 4 is high. Maybe Lowest, Low, High, Highest? Or Low, Medium, High, Highest, or something.
Re: Repository package managers
I guess 4 or 5 mirrors at a time would be enough and Low, Medium, High, Highest sounds good.Sparky wrote:So, just to be clear before I begin design planning, it should support up to 4 mirrors at a time, each with a different priority? Priorities might be better as words, instead of numbers, so that users aren't confused about when 1 is high or 4 is high. Maybe Lowest, Low, High, Highest? Or Low, Medium, High, Highest, or something.
Example:
Highest: Alcoholix mirror
High: Slackware mirror
Normal: Zenwalk mirror
Low: linuxpackages.net
Re: Repository package managers
It should support up to any number of mirrors! Don't really think that it would be much more difficult to code than only 4-5.
We need at least 4 levels of priority. Naming them would be better, yes. I think Low-Normal-High-Very high is good.
It couId possible for two different repos to have the same priority. If a package is present in two repos with the same priority, the highest version should be chosen, and if there is a version match, the highest build number.
We need at least 4 levels of priority. Naming them would be better, yes. I think Low-Normal-High-Very high is good.
It couId possible for two different repos to have the same priority. If a package is present in two repos with the same priority, the highest version should be chosen, and if there is a version match, the highest build number.
Re: Repository package managers
And a bit off-topic: I don't think we should have zenwalk mirrors in our repos list. Zenwalk has deviated a lot from slackware and will definitely run into incompatibilities using packages from it. There will be other problems too with zenwalk packages needing zenwalk dependencies, like the sdl package for example, which is a lot different that the slackware sdl. There is also no version match for a given slackware version, so we wouldn't know what repository to use anyway.
But we could certainly have slacky and gnome slackbuilds for example, so there would be no shortage of packages from the very start.
But we could certainly have slacky and gnome slackbuilds for example, so there would be no shortage of packages from the very start.
Re: Repository package managers
Development on this is sort of slow because I am having to re-write a lot of it from scratch to accommodate multiple mirrors, but it is gradually getting done.
I need to know though, when a package exists multiple times on the set of active mirrors, what should happen? Should different versions get their own entries, or should only the package from the highest priority mirror be displayed? What if that mirror has multiple versions of a package on it, should they all be displayed?
I need to know though, when a package exists multiple times on the set of active mirrors, what should happen? Should different versions get their own entries, or should only the package from the highest priority mirror be displayed? What if that mirror has multiple versions of a package on it, should they all be displayed?
Re: Repository package managers
gslapt displays all versions with multiple entries. But maybe you can do both, by having a switch in Preferences or something?Sparky wrote:I need to know though, when a package exists multiple times on the set of active mirrors, what should happen? Should different versions get their own entries, or should only the package from the highest priority mirror be displayed?
That should never happen I think. But even if it does, maybe it could obey to the same switch?Sparky wrote:What if that mirror has multiple versions of a package on it, should they all be displayed?