I added the next4 / ext4dev / ext4 with snapshots mailing list in
copy, just in case they wanted to comment.
On Tue, Sep 20, 2011 at 5:34 PM, Jan Engelhardt
On Tuesday 2011-09-20 23:10, Greg Freemyer wrote:
obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version
I've got a project that may need this.
== background == I am working with the next4 team and they have a ext4dev patch[...] My need. To go with the above module, e2fsprogs has to be extended to have the legacy programs mkfs.ext4dev, fsck.ext4dev, etc. handle this new definition of ext4dev (ext4dev is unused since the 2.6.29 kernel I think).
Yeah perhaps one should not call the effort 'ext4dev' but maybe 'ext4 with snapshots' :-)
It actually started 18 months ago or more as next4 (ext4 with snapshots). At some point and I believe with the support of the ext4 maintainer (Ted Tso) it was decided to leverage all the unused infrastructure related to the initial ext4dev rollout. When ext4 was rolled for production in the 2.6.30 timeframe, ext4dev basically became a legacy designation. So e2fsprogs, xfstests, and I guess other code has a support base for ext4dev, but no current use case. Obviously to enable this new code, the filesystem type would need: - to be ext4dev, - a new snapshot feature bit would need to be set on the filesystem, (that feature bit has been reserved in the ext4 superblock by Ted T'so for a year or more I believe) - the new ext4dev userspace tools would be needed. I'm not sure how / when Ted plans to rollout out next4/ext4dev/ext4 with snapshots. He's been saying for about 6 months that he would try to review the patches and get it into the next merge window. Obviously that has not happened yet. The patch itself is based on a production Filer that has been commercially sold for a couple years. So it has had a lot of field testing.
My issue is in the packaging. I doubt I should submit a patch to update the core e2fsprogs package, so I was thinking of creating a e2fsprogs-ext4dev package. [...] handling the package name, provides, and obsoletes logic?
By using Obsoletes/Provides in this case, you enact zypper to automatically select your package during dependency resolution of another package's dependencies (say, perl-Bootloader).
This of course is undesired, since your package contains components that are considered "fragile" by your very own definition.
IOW, no Obsoletes/Provides for your case.
I admit to not thinking about that. Just to be clear, the "fragile" components have legacy names which no one should be using. And they in and of themselves don't do anything special unless the user has also installed the ext4dev kernel module. So I don't think the new functionality could occur accidentally. ---- The patch I have causes a change to mkfs.ext4dev, etc. All the other instances of mkfs.* should be the same as the main package. Since mkfs.ext4dev are in normal e2fsprogs but use the same code as mkfs.ext4, my thought was to have my new e2fsprogs-ext4dev package simply redundantly provide everything in e2fsprogs. Is there a better way to cause my versions of *.ext4dev to be installed and not the ones from e2fsprogs? I guess I could submit a e2fsprogs patch to have it not build *.ext4dev, and then have my package (e2fsprogs-ext4dev) only provide those? Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org