xfsdump

[Jason W]

xfsdump for dumping and restoring an XFS filesystem:

Code: [Select]

Title:          xfsdump.tce
Description:    Administrative utilities for the XFS filesystem.
Version:        3.0.0
Author:         SGI XFS development team
Original-site:  http://oss.sgi.com/projects/xfs/
Copying-policy: GPL
Size: 276kb
Extension_by:   Jason W
Comments:       This extension is PPI compatible.
Change-log:     ----
Current:    2009/03/23 First version


Code: [Select]

Title:          xfsdump.tcz
Description:    Administrative utilities for the XFS filesystem.
Version:        3.0.0
Author:         SGI XFS development team
Original-site:  http://oss.sgi.com/projects/xfs/
Copying-policy: GPL
Size: 327kb
Extension_by:   Jason W
Comments:       ----
Change-log:     ----
Current:    2009/03/23 First version


[curaga]

- 276 megabytes? not kb?
- should this not be in xfsprogs, seeing how it very closely relates to it?

I better follow up with JFS utils soon

[Jason W]

It's KB and not MB.  I'll fix it.   

Since the xfs extensions go together like peas and carrots, why not just make one extension out of it?  There are exceptions, but as a matter of principle I prefer modularity over packing related libs and apps in one extension now that we have dep files.  If an extension is self contained in /opt or a specific directory beneath /usr/local then it does not matter what is in it as the libs in a self contained extension do not conflict with ones installed in /usr/local itself.   But for the way we install extensions now I prefer the practice of one lib equals one extension and using dep files to meet dependencies.  When someone comes along and wants to create an extension that depends on a lib that is packed in with another extension, they have two choices.  Say the lib they need is 50kb and the extension it is packed in is 5MB.  They can either put the 5mb extension as a dependency, or create an extension for the same version of the lib that is contained in the extension so the overwriting causes no conflicts.  If one only needs the small lib as a dependent, then that is all they should have to install.  I am not criticizing or trying to influence the way others make extensions but this is just my preference.  Of course, extensions like compiletc and Xorg are exceptions as those are large and specialty extensions that serve well to be on their own, and there are others too.  And some apps and libs have no others that use them, so in that case it makes perfect sense to put them together.

With the xfs extensions, xfsdump depends on acl, attr, and xfsprogs.  Acl is listed in the Arch repo as having 14 packages that depend on it, and attr has 4.  And in time someone may make an extension that needs acl and not the xfs stuff and they can just put acl in their dep file.  Acl at 30kb gets installed as a dep instead of a collective xfs extension  that is 1.3MB.  Even if xfsdump and xfsprogs were just binaries without any libs involved, someone may still want xfsprogs and not xfsdump.  This keeps the installed system smaller and leaner. 

I hope this is not taken as critical of how others make extensions.  But I did want to at least explain my approach and the reasons why. 

[Jason W]

Curaga,
I'm sorry for writing a discourse on extension making like that.   I should have pm'd you instead if I was going to discuss extension concepts.  I didn't mean it as a lecture, as you certainly don't need a lecture on extension making.  I'm the one learning from you guys.  You are good about keeping discussions or concerns with me in private, and I had said I would give you the same courtesy you give me.  I will remember in the future.

Upon a closer look, there is almost zero chance that a future extension will require one of these SGI specific libs or apps.  Including acl, attr, xfsprogs, and xfsdump in one extension makes perfect sense, and they will almost never be used apart from the other.  Sometimes I just take a concept or principle and run with it, not tempering it with common sense.

JW

[tobiaus]

Curaga,
I'm sorry for writing a discourse on extension making like that.   I should have pm'd you instead if I was going to discuss extension concepts.

if it was solely for curaga, i can see how it might be better to do that privately than risk chafing 'egos' (i use the term loosely, i have a lot of admiration for you and curaga and your collective skills, not to mention generosity,) but i agree strongly with your ideal. as you point out, it isn't to say everyone should (or shouldn't) do it "our way," but i'm glad you posted in public this time. i didn't see a personal attack on curaga and i hope he won't either. i just see it as an option, an explanation, and a good idea.

[curaga]

It's ok, I didn't take it badly

In fact I wonder why is xfsdump separate from the progs in upstream at all. It's just another filesystem-related utility, and by common sense should be together, like e2label is in e2fsprogs.

[Jason W]

The four packages from upstream would be fine together.  Our ext2 and ext3 does not support posix acl's, so XFS is the only fs that would use it.  So the attr and acl stuff is exclusively for xfs. 

The next time I deal at all with the xfs utilities I can put them together as they are xfs exclusive.