[yocto] Cleanly moving files from one package to another

[Martin Jansa]

On Thu, Dec 10, 2015 at 04:20:45PM +0000, Bryan Evenson wrote:
> Martin,
> 
> > -----Original Message-----
> > From: Martin Jansa [mailto:martin.jansa at gmail.com]
> > Sent: Thursday, December 10, 2015 9:39 AM
> > To: Bryan Evenson <bevenson at melinkcorp.com>
> > Cc: yocto at yoctoproject.org
> > Subject: Re: [yocto] Cleanly moving files from one package to another
> > 
> > On Thu, Dec 10, 2015 at 02:15:05PM +0000, Bryan Evenson wrote:
> > > Martin,
> > >
> > > > -----Original Message-----
> > > > From: Martin Jansa [mailto:martin.jansa at gmail.com]
> > > > Sent: Thursday, December 10, 2015 4:20 AM
> > > > To: Bryan Evenson <bevenson at melinkcorp.com>
> > > > Cc: yocto at yoctoproject.org
> > > > Subject: Re: [yocto] Cleanly moving files from one package to
> > > > another
> > > >
> > > > On Wed, Dec 09, 2015 at 08:19:40PM +0000, Bryan Evenson wrote:
> > > > > All,
> > > > >
> > > > > I'm on poky/dizzy-1.7.3 and I'm using opkg for a package manager.
> > > > > I have a
> > > > few script files that are part of one package that really belong with
> > another.
> > > > So I updated both recipes, removed the file from one recipe and
> > > > added it to the other recipe.  I built everything, made the opkg
> > > > feed repo and tried to upgrade with "opkg update; opkg upgrade" to
> > > > see how clean the upgrade was.  For each script file I moved from
> > > > one package to the other I get an error message of the form:
> > > > >
> > > > > * check_data_file_clashes: Package A wants to install file
> > > > /path/to/script/file
> > > > >         But that file is already provided by package  * B
> > > > >
> > > > > I know I can do "opkg upgrade --force-overwrite", but I'd like to
> > > > > make
> > > > recipe changes so that it upgrades cleanly.  All I've done in the
> > > > recipes is remove the script files from the FILES variable and the
> > > > do_install step of one recipe and added the script to the FILES
> > > > variable and do_install step of the other recipe.  I know
> > > > update-alternatives can be used if more than one package provides
> > > > the same binary, but is that necessary in this case when
> > > > transferring ownership to another package?  Is there anything else I can
> > do in the recipes to prevent the opkg install errors?
> > > >
> > > > Have you tried to set
> > > > RREPLACES_<pkg-new> = "<pkg-old>"
> > > > ?
> > >
> > > I haven't tried that because I'm not replacing a package.  Both packages still
> > exist on the system and are both needed, it's just that ownership of one of
> > the files is being transferred from one package to another.  Would I still use
> > RREPLACES even if I want to keep both packages on the system?
> > >
> > > Specifically in this case, I have some script files for scheduled tasks that
> > were part of one of my self-made packages.  However, they really belong
> > with cronie since this is what is calling the scripts.  So I removed the script files
> > from my self-made package and added them to cronie.  My package has
> > other files still associated with it (that do belong with it) installed on my
> > system.  So I want to keep both packages on my system, but I just want to
> > change ownership of these script files from my package to cronie.  Is
> > RREPLACES the tool for this job?
> > 
> > > Is RREPLACES the tool for this job?
> > 
> > Yes, see
> > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-
> > replaces
> > 
> > opkg should work the same.
> 
> Now I'm having something happen that I haven't seen before with the PR service.  I updated my .bbappend to add the RREPLACES as you suggested, but bitbake didn't rebuild the package.  I tried doing bitbake -c clean and bitbake -c cleansstate and both times the built package had the same full version number as it did before I made the RREPLACES change.  I opened the ipk with Archive Manager and looked at DEBIAN/control, and there was no "Depends: " line in the control file.  Then I noticed that this .bbappend had "inherit pkgconfig" and it isn't needed in the .bbappend.  So while I was at it I deleted the line "inherit pkgconfig" and tried to build the package again (without issuing a bitbake -c clean first).  This time it built the package and the PR service incremented the version.  I opened the resulting ipk and looked at DEBIAN/control again, and this time there was a "Depends:" line in the control file.
> 
> Is changing RREPLACES not being seen as a metadata change by bitbake?  Is this a bug or is there something else I'm missing?

It should invalidate sstate signature for do_package* task
(maybe just do_package_write_ipk), if it doesn't then it's a bug.

Best way to test this is to use bitbake -S package, before and after
such change and bitbake-diffsigs on generated .sigdata files to see if
it was noticed by bitbake.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20151210/4a700680/attachment.pgp>