James Antill — LiveJournal
Aug. 24th, 2008
After seeing the article on sudoku in apt/dpkg, I naturally thought "I wonder how you can do that in rpm". The big differences (from what I read/understood of the article) being that rpm doesn't mind if two packages with the same virtual provide are installed at once where dpkg does (and their "game" relies on that).
The natural solution seemed to be to use provides and conflicts, although I didn't think of other forms for long before just trying to implement that one :). The basic premise is to have 9 * 9 * 9 packages, each providing cell_1.1.1 through cell_9.9.9 (which is the row, column and value) and cell_value_1.1 through cell_value_9.9 (just the row and column). Then require all 82 cell_values, with any specific cells. You then just add conflicts in each package obeying the rules for block, row and column. Simple.
I was pretty sure yum would fail at solving the sudoku puzzles, because it basically requires that when you get multiple answers to a provides question (what package provides cell_1.1) you need to repeatedly narrow it down based on future information. This is kind of on the longer term. road map for yum so that it'll get better results, in certain edge cases, for real packages in real repositories.
Read on for scripts/repos. and results (spoiler, yum does fail and smart succeeds).( Read more...Collapse )
Aug. 12th, 2008
As you create packages for private use, the question will eventually come up "where do I put these". The choice is obvious for the first package, just create a repo. (using createrepo -d) and distribute the my.repo file. However as you create more packages the answer should expand to having multiple repos. Different package managers have a different ideas about what should go inside a single repository, and the corollary to that is if you take the "best practice" for some other package manager and apply it to yum the results might not be all they could be. This posting will try and lay out the best practises for yum (3.2.z), and some of the reasons for them.( Read more...Collapse )
Aug. 7th, 2008
11:40 pm - Understanding groups in yum
Every now and again someone will will ask a question about groups in yum that amounts to:
( Read more...Collapse )
If I do "groupinstall xyz" and then I do "groupremove xyz" why do I not end up where I started.
May. 21st, 2008
The previous entry was more of a general explanation about YUM speed and that if used in it's normal environment how current YUM is often more than fast enough, this entry is going to be a companion to it but focus on specific things that might make YUM appear slow but would better be described as using it suboptimally.
Note that I'm still not going to directly compare to other tools as I'm not as familiar with them and, as I said in the previous article, the tools are designed so differently that they don't lend themselves to comparisons. Also, as I also said before, if something is fine if it takes less than 10 seconds if two tools take 6 seconds and 4 seconds it doesn't really matter if yum is the faster (again, see the previous post, this should not be the end goal IMO).( Read more...Collapse )
May. 20th, 2008
As a YUM developer it's hard not to notice the number of complaints/attacks on YUM about it being slow and/or using too much memory, the most common thing about almost all of these complaints though is how inaccurate they are. To be clear, YUM did used to take a lot more time than was required to do simple operations and there are very likely some more improvements that can be made for certain situations BUT yum is currently "not slow" at most normal operations for Fedora users and RHEL/CentOS users should be getting a much newer/faster variant than they currently have in the very near future.( Read more...Collapse )
As a final note I'd say that the biggest reason a lot of these recent complaints annoy me is not just that they are inaccurate but that they tend to grossly mislead the reader into thinking that "package management" is a solved problem and the biggest obstacle to solve is whether "install foo" takes 3 seconds or 6 seconds. In my opinion this could not be further from the truth, managing 2-6 machines is an ugly problem in all the current solutions and managing 100-10,000 is basically not done. Then there are things like the 10x10 problem, where we are only starting to see ideas like KOPERS which might help solve the problem (but will require changes in the way package management is assumed to work). And that's completely ignoring the problems that have had attempted solutions (that failed) multiple times, like "rollback" support.
May. 6th, 2008
02:22 am - Python uses too much memory?
There's a common attack leveled against Python applications that they take up too much memory, by people who understand the language difference (against, say, C) and by people just looking at their process list. This is often esp. evident on the newer x86_64 computers.
So as the Fedora Python maintainer, and a yum developer (an application written mostly using python), I figured it was probably worth investigating what the difference really was.( Read more...Collapse )
Jan. 8th, 2008
Feel free to pick me up and jiggle me about before asking other questions obviously answered by crappy human nature:
Obama to win over Hillary, March 1st, 2007 05:07 pm
Oct. 4th, 2007
I saw three things recently which just confirmed that noone learns anything:
- The "we don't need a real string API" on the GIT mailing list, followed by almost a month now of struggling to implement another one (and wishing they had some of the ustr features).
- GLibc's proposed fix for C/POSIX not having a usable string API. Yes, it's the old let's all pretend IO (FILE *) is a good string abstraction ... you need to add, search/etc, and then add some more? Well multiple copies were always good fun, pretty much guaranteeing people will do a bunch of workarounds if they use it at all.
- The Linux kernel is again looking for yet another almost a worthwhile string API, pretending it'll only be useful for this specific IO type ... because seq_printf() wasn't unique enough.
Best quote by far, IMO (from the GIT thread):
"Please, no. Let's not pull in a dependency for something as simple as a string library." -- Kristian Høgsberg
As a minor good note, ustr is in Fedora and so pretty much everyone in Fedora land has access to a usable string API with a single -l ... and the newer versions of libsemanage (SELinux) use ustr. I'm not going to hold my breath for mass sanity to occur though.
Sep. 15th, 2007
02:00 am - The last 10%
ustr a rough timeline, notes on the last 10%
Common software development wisdom says "the last 10%" is often a significant time consumer, if not 50%, of the work. So when I recently created ustr, I thought I had a pretty good candidate to get some real numbers. For a start, in my favour, I'd already created Vstr and so knew most of the interfaces I'd want and roughly how to write them.( Read more...Collapse )
Jun. 20th, 2007
First off, I hate all current software packaging for Linux. It's one step up from manually downloading tarballs, which I was doing 10 years ago, and isn't even a real superset of that functionality. Yes, it's better than doing that and yes it's better than what Windows has to offer. But it's still crap, and it annoys me every day, however it seems to be one of those problems that noone seems to want to fix properly and yet they keep thinking up stupid bandaids to work around the fact it doesn't work well. Specifically the major circular argument that is what I've come to think of as the "10 × 10 problem"…( Read more...Collapse )