3743 2013-01-17 11:45:32 +0000 Packaging license texts 2014-07-21 16:32:45 +0000 1 1 7 Build System, Metadata & Runtime OE-Core configuration 1.4 x86 Multiple RESOLVED FIXED Medium enhancement 1.7 1 Martin.Jansa elizabeth.flanagan bluelightning elizabeth.flanagan jessica.zhang sgw --- --- Don't know oldest_to_newest 28891 0 Martin.Jansa 2013-01-17 11:45:32 +0000 We would like to include license texts (generic LICENSE + LIC_FILES_CHKSUMs) in PN-lic to install them on target. http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/032174.html I've talked with Beth about this: Tue Nov 27 18:50:49 2012: 18:24 <pidge> hey martin, I have some questions about what you're looking for with license.bbclass 18:26 <JaMa> hi 18:27 <pidge> hiya 18:27 <pidge> I want to understand a bit more fully what you're looking to do 18:28 <JaMa> currently there is license in package metadata and opkg shows it 18:28 <pidge> yes 18:28 <JaMa> for proprietary packages we would like to also package license text in main package 18:28 <JaMa> so that on target device you can actually read what license 'proprietary-foo' says 18:29 <pidge> ah, ok 18:29 <pidge> so, a few things 18:29 <pidge> you know about LICENSE_PATH I assume 18:29 <JaMa> so such functionality should add do_install_append which copies files referenced by LIC_FILES_CHKSUM to some unified location 18:30 <pidge> yes, that'd kind of what I was thinking. 18:31 <JaMa> I'm not sure if LICENSE_PATH is what I'm looking for 18:32 <pidge> no, only for adding the custom generic 18:32 <pidge> ok, so... one way to do it is with COPY_LIC_MANIFEST and COPY_LIC_FILES but I don't think it will do exactly what you want. 18:33 <pidge> if I understand correctly, what you want is for the license text to be added to the package so when the package is installed it's added to the image. 18:33 <pidge> that sound about right? 18:33 <JaMa> ah reading COPY_LIC_DIRS + COPY_LIC_MANIFEST once again looks close to what we want 18:34 <JaMa> yes it's close, but doesn't solve when some package is installed by opkg after image creation 18:34 <pidge> yeah. not exact, but I think what you're asking for may be more useful in certain use cases 18:34 <pidge> right 18:35 <pidge> and honestly, we should be packaging with licenses anyway 18:35 <JaMa> I think what I want can replace COPY_LIC_DIRS + COPY_LIC_MANIFEST 18:35 <pidge> so, I think the right place to do this is within package.bbclass 18:36 <JaMa> because with licenses in packages itself you don't need to create manifest and license dir on rootfs time 18:37 <pidge> some people do require the manifest. but yeah, I think that doing it via the packager is cleaner. 18:37 <pidge> hrm....... 18:37 <pidge> ok, how does this sound.... 18:38 <pidge> on do_package the packager grabs the license text and also creates the spdx metadata and packages it up with everything. 18:38 <JaMa> looks good to me 18:39 <pidge> on do_install if COPY_LIC_MANIFEST is set, we do_install_append to tack on the spdx metadata to the main manifest. 18:39 <JaMa> there is also option to add PN-license with only license included and add PN-license to PN RDEPENDS 18:39 <pidge> and COPY_LIC_DIRS sets up if we package with license text 18:40 <JaMa> but in both cases there is issue with "shared" license text as 2 packages cannot install the same file 18:40 <JaMa> so you can install bigger package with all common-licenses included and then PN installs just symlink which is unique 18:40 <pidge> hrm. right. but they can install a simlink heh, exactly 18:40 <JaMa> or you have to duplicate common license text for each package 18:41 <pidge> simlinks, or else dvhart will have my head ;) 18:41 <JaMa> then there is problem how to generate that big package with all common-licenses :) 18:41 <pidge> poky-tiny will no longer be tiny without that 18:42 <JaMa> it should include all licenses (not only those used on rootfs time) to catch all those ipk files only in feed 18:42 <pidge> hrm.... yeah. can opkg do a conditional install? if the file exists, install? 18:42 <pidge> does not exist 18:42 <pidge> hrm... 18:42 <JaMa> and if it includes all then you have to bump PR or something in such package when common/licenses directory is changed in git 18:43 <pidge> yeah, I think having 168 different common licenses on an image won't fly] 18:43 <pidge> let me think of a cleaner way here. 18:43 <JaMa> or generate package for each license :) 18:44 <JaMa> then PN which wants to install just symlink to shared license will just set right RDEPENDS to install shared license text 18:45 <pidge> hrm. let me look at the package bbclasses. I think there is a way to do this conditionally, which would be the best way to do this I'll send pull request implementing first part which is good enough for us to use it in package manager, but it doesn't handle shared generic licenses. 28893 1 Martin.Jansa 2013-01-17 11:51:13 +0000 Patches sent to oe-core ML for review: http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/034395.html http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/034396.html http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/034397.html 31968 2 bluelightning 2013-04-11 14:15:09 +0000 These patches have been merged to master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2daab0b3a233f8e322e024338b158e0b0a16967f http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=15aa7134826bcdd54f548454991d531d9db3b3b3 Leaving open because it looks like there may be additional functionality to implement, is that still correct Martin? 31970 3 Martin.Jansa 2013-04-11 14:24:10 +0000 (In reply to comment #2) > These patches have been merged to master: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/ > ?id=2daab0b3a233f8e322e024338b158e0b0a16967f > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/ > ?id=15aa7134826bcdd54f548454991d531d9db3b3b3 > > Leaving open because it looks like there may be additional functionality to > implement, is that still correct Martin? Yes, it creates PN-lic packages if enabled, but without any optimization to share texts of common licenses between packages. 43051 4 elizabeth.flanagan 2014-04-28 19:40:02 +0000 Resolved in: 43946 5 bluelightning 2014-06-13 16:03:04 +0000 So is this resolved now, or not? (I'll admit, I haven't checked the code.) 44247 6 elizabeth.flanagan 2014-06-30 20:44:06 +0000 This has been resolved for a while. Closing. 44254 7 Martin.Jansa 2014-06-30 23:20:18 +0000 (In reply to comment #6) > This has been resolved for a while. Closing. Not completely. It was merged without any optimization to share texts of common licenses between packages, which we originally discussed. But I'm ok with keeping it resolved.