Mailinglist Archive: opensuse-packaging (205 mails)

[Greg Freemyer <greg.freemyer@xxxxxxxxx>]

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 <jengelh@xxxxxxxxxx> wrote:
> 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-retrieved/

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx