Aaron Griffin wrote:

On Dec 1, 2007 12:10 AM, Michael Towers wrote:

...

I recently posted a feature request for the aufs dependency on aufs-utils to be removed (because the latter is not necessary for using aufs). The bug was closed by the maintainer because "This is the standard way of packaging modules in Arch:

http://wiki.archlinux.org/index.php/Kernel_Module_Package_Guidelines".

Of course he was right: "... make sure nvidia depends on nvidia-utils ..."

It's maybe a rather small point, but to me this requirement seems a bit excessive. I would suggest rephrasing this to:

"... if nvidia-utils is required for the use of nvidia, make sure nvidia depends on nvidia-utils ..."

Arch has never been in the business of satisfying one user because "I like it this way instead". In fact, that's what makes us unique. We do things the way WE see fit, and give YOU the tools to change what you don't like.

Feel free to recompile aufs via ABS (or even yaourt) if you'd like to remove the dep

In fact, if you use srcpac, you can install it with a sed line in the config, and srcpac -Syu will fix it every time.

Like I said - we provide the tools. I just gave you three options. It's up to you to use one of them, or make a 4th option

Sorry if I somehow caused offence. I don't want to start a fight! But I would have preferred an answer along the lines of ... "The reason this dependency must be there is ...". In the case of aufs it is of course something I can work around (I already have), I was just under the impression that unnecessary dependencies were generally undesirable in Arch.

On Sun, 2 Dec 2007 15:23:57 -0600 "Aaron Griffin" wrote:

I still can't understand why this is a problem though... according to pacman, the installed size is 12K, and the only possible reason I could think of for caring about this dep is size.... could you please explain the rationale here?

I understand Michael's point, I think. He's not talking about the aufs package at all, but using it as an example for the rule in the Packaging Guidlines that says modules should always depend on their utilities, even when you can use the modules without them. He wasn't complaining about not getting things exaclty as he wants them, he was only asking a curious question. He wants to know the reason for this exception to the rule of packages only depending on what the package needs to be useful. To me it seems your answer is: We don't have a reason, and stop bothering us with stupid questions. Or is it; it's ok with deps that are not necessary as long as they're small? Although it's a bit pedantic, I think he has a point too. If you should follow this principle all the way, the kernel26 package should depend on cryptsetup, nfs-utils, dosfsutils, fuse, iptables, ntfsprogs etc., you get my idea..

On Dec 2, 2007 6:19 PM, Robert Emil Berge wrote:

...

On Sun, 2 Dec 2007 15:23:57 -0600 "Aaron Griffin" wrote:

...

I still can't understand why this is a problem though... according to pacman, the installed size is 12K, and the only possible reason I could think of for caring about this dep is size.... could you please explain the rationale here?

Although that wasn't my main point, the rationale in the case of aufs is

Aaron Griffin wrote: that the utils package modifies the behaviour of the mount command by providing the (normally unnecessary) helper script mount.aufs, which in turn depends on various other packages (sed, grep, awk, diff, ...). It's no big deal, and these will normally be installed anyway, and it is also possible to stop the helper script from being called, and ... It's just that in the case of aufs - which might well be used in a situation where these utilities aren't available - it could be a bit annoying, especially if the aufs-utils dependencies were fixed to include all these things which I might not want (and which would increase the total size to significantly more than 12k).

...

I understand Michael's point, I think. He's not talking about the aufs package at all, but using it as an example for the rule in the Packaging Guidlines that says modules should always depend on their utilities, even when you can use the modules without them. He wasn't complaining about not getting things exaclty as he wants them, he was only asking a curious question. He wants to know the reason for this exception to the rule of packages only depending on what the package needs to be useful.

Exactly.

...

To me it seems your answer is: We don't have a reason, and stop bothering us with stupid questions. Or is it; it's ok with deps that are not necessary as long as they're small?

Although it's a bit pedantic, I think he has a point too. If you should follow this principle all the way, the kernel26 package should depend on cryptsetup, nfs-utils, dosfsutils, fuse, iptables, ntfsprogs etc., you get my idea..

The rationale is that the aufs and aufs-utils packages are actually part of the exact same source tarball and are simply separated due to the fact that we support multiple kernels. As such, the _original author_ intended them to be used together.

squashfs-tools and unionfs-utils are also part of the same source packages as their respective modules, but the kernel doesn't depend on these. In the case of aufs, the original author says in the documentation that the utils are optional (even if he did intend them to be used together with the module, he didn't necessarily intend the module to be used together with the utils). I can live with the situation as it is, I actually only wanted to point out a possible inconsistency and an easy and painless way to remove it.

Aaron Griffin wrote:

On Dec 3, 2007 12:09 AM, Michael Towers wrote:

...

I can live with the situation as it is, I actually only wanted to point out a possible inconsistency and an easy and painless way to remove it.

Well, actually - and here's the reason I'm being defensive here. You pointed out the inconsistency on the bug tracker, and the package maintainer said "no", so you escalated the issue to the community at large. It's that escalation that is tiresome to me.

Sorry (really!) to be pedantic, but it was two separate issues. Firstly, not knowing of the guideline requiring module utils to be a module dependency I requested the removal of the dependency I requested the removal of the dependency. Then, learning of the guideline I asked on this list for opinions as to whether that could be changed slightly to be (IMHO) more in line with general Arch policy.

Now, excepting all that, in a way, I agree with you to a small extent. If the author specifically lists the utils as optional, then they're optional. Request a reopening of the bug report linking to that documentation.

How should one request that a bug be reopened? But suppose the dependency in aufs was removed. Then it would be in conflict with the module packaging guideline, as it stands. Normally in such a situation I would open a feature request to change that line in the guideline, but your responses here suggest that there wouldn't be much point ... (And where would the correct place for that be anyway? It's not a package, so maybe not Flyspray? The discussion page? Does anyone read that? ...)

On Dec 4, 2007 12:41 AM, Michael Towers wrote:

but your responses here suggest that there wouldn't be much point ...

That's not entirely true. My responses here are based more on the fact that what you see as a problem, I see as something you _should_ solve for yourself. I know it makes me difficult and all, but I see this sort of stuff a lot - one user wants a change so _we_ must change for them. Yada yada, it's tedious. In this case, I feel like you have a problem with one package, and see the guidelines at fault, but you could simply rebuild the package to fit your own personal guidelines.

(And where would the correct place for that be anyway? It's not a package, so maybe not Flyspray? The discussion page? Does anyone read that? ...)

Flyspray says nothing about packages in the default category. It is named "Arch Linux" because it is general to the distro. That Project has sub-categories which include "Packages: Extra", "System", "Installation" and more

Just a heads up if there are still any other i586 archers out there: glibc 2.7 needs an extra patch to compile for CHOST=i586. PLD Linux has the patch here: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/glibc-i586-build-fix.pat... Cheers. Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/