Skip to contentSkip to conversation

unique -dev package

RFC PATCH In review Robert Yang 6 participants 16 messages Apr 7, 2015 – Apr 11, 2016

lore
Share & tools
lore
#0 lore raw

cover unique -dev package

Hello,

I think that one recipe should only have one -dev package, I'm not sure whether this is right or not, please feel free to give your comments, we still have about 30 recipes in oe-core which have more than one dev packages, more info:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7481

// Robert

The following changes since commit fbaddd724855a829698d853a70eee86118d6a5e7:

  package_manager: call createrepo with --dbpath pointing inside WORKDIR (2015-04-02 12:00:55 +0100)

are available in the git repository at:

git://git.openembedded.org/openembedded-core-contrib rbt/dev
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/dev

Robert Yang (2):
xz: remove xz-dev from PACKAGES
bzip2: remove bzip2-dev from PACKAGES

 meta/recipes-extended/bzip2/bzip2_1.0.6.bb |    3 ++-
 meta/recipes-extended/xz/xz_5.2.0.bb       |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)
Signature · 1 line
1.7.9.5
#1 lore raw

RFC PATCH 1/2 xz: remove xz-dev from PACKAGES

There should be only one dev package which is liblzma-dev, so remove xz-dev.

---
 meta/recipes-extended/xz/xz_5.2.0.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-extended/xz/xz_5.2.0.bb +1 -1
index 3439ec9..8c3eb13 100644
@@ -8,7 +8,6 @@ SECTION = "base"
 # appears to be used for DOS builds. So we're left with GPLv2+ and PD.
 LICENSE = "GPLv2+ & GPLv3+ & LGPLv2.1+ & PD"
 LICENSE_${PN} = "GPLv2+"
-LICENSE_${PN}-dev = "GPLv2+"
 LICENSE_${PN}-staticdev = "GPLv2+"
 LICENSE_${PN}-doc = "GPLv2+"
 LICENSE_${PN}-dbg = "GPLv2+"
@@ -31,6 +30,7 @@ SRC_URI[sha256sum] = "231ef369982240bb20ed7cffa52bb12a4a297ce6871f480ab85e8a7ba9
 inherit autotools gettext
 
 PACKAGES =+ "liblzma liblzma-dev liblzma-staticdev liblzma-dbg"
+PACKAGES_remove = "xz-dev xz-staticdev"
 
 FILES_liblzma = "${libdir}/liblzma*${SOLIBS}"
 FILES_liblzma-dev = "${includedir}/lzma* ${libdir}/liblzma*${SOLIBSDEV} ${libdir}/liblzma.la ${libdir}/pkgconfig/liblzma.pc"
Signature · 1 line
1.7.9.5
#2 lore raw

RFC PATCH 2/2 bzip2: remove bzip2-dev from PACKAGES

In reply to Robert Yang

There should be only one dev package which is libbz2-dev, so remove bzip2-dev.

---
 meta/recipes-extended/bzip2/bzip2_1.0.6.bb |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes-extended/bzip2/bzip2_1.0.6.bb +2 -1
index ed12277..d1d1c8d 100644
@@ -17,6 +17,7 @@ SRC_URI[md5sum] = "00b516f4704d4a7cb50a1d97e6e8e15b"
 SRC_URI[sha256sum] = "a2848f34fcd5d6cf47def00461fcb528a0484d8edef8208d6d2e2909dc61d9cd"
 
 PACKAGES =+ "libbz2 libbz2-dev libbz2-staticdev"
+PACKAGES_remove = "bzip2-dev bzip2-staticdev"
 
 CFLAGS_append = " -fPIC -fpic -Winline -fno-strength-reduce -D_FILE_OFFSET_BITS=64"
 
@@ -35,7 +36,7 @@ do_install_ptest () {
 
 FILES_libbz2 = "${libdir}/lib*${SOLIBS}"
 
-FILES_libbz2-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV}"
+FILES_libbz2-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/lib*.la"
 SECTION_libbz2-dev = "devel"
 RDEPENDS_libbz2-dev = "libbz2 (= ${EXTENDPKGV})"
 
Signature · 1 line
1.7.9.5
#3 lore raw

Re: [RFC PATCH 2/2] bzip2: remove bzip2-dev from PACKAGES

Quoted 18 lines · Robert Yang

There should be only one dev package which is libbz2-dev, so remove bzip2-dev.

---
meta/recipes-extended/bzip2/bzip2_1.0.6.bb | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes-extended/bzip2/bzip2_1.0.6.bb +0 -0
index ed12277..d1d1c8d 100644
@@ -17,6 +17,7 @@ SRC_URI[md5sum] = "00b516f4704d4a7cb50a1d97e6e8e15b"

SRC_URI[sha256sum] = "a2848f34fcd5d6cf47def00461fcb528a0484d8edef8208d6d2e2909dc61d9cd"

Quoted 2 lines

PACKAGES =+ "libbz2 libbz2-dev libbz2-staticdev"
+PACKAGES_remove = "bzip2-dev bzip2-staticdev”

why remove ${PN}-dev ? others should be removed IMO

Quoted 20 lines

CFLAGS_append = " -fPIC -fpic -Winline -fno-strength-reduce -D_FILE_OFFSET_BITS=64"

meta/recipes-extended/bzip2/bzip2_1.0.6.bb +0 -0
@@ -35,7 +36,7 @@ do_install_ptest () {
 

FILES_libbz2 = "${libdir}/lib*${SOLIBS}"

meta/recipes-extended/bzip2/bzip2_1.0.6.bb +1 -1
-FILES_libbz2-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV}"
+FILES_libbz2-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/lib*.la"

SECTION_libbz2-dev = "devel"
RDEPENDS_libbz2-dev = "libbz2 (= ${EXTENDPKGV})"

Signature · 7 lines
1.7.9.5

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
#4 lore raw

Re: [RFC PATCH 2/2] bzip2: remove bzip2-dev from PACKAGES

Quoted 18 lines · Khem Raj
Quoted 18 lines · Robert Yang

There should be only one dev package which is libbz2-dev, so remove bzip2-dev.

---
meta/recipes-extended/bzip2/bzip2_1.0.6.bb | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes-extended/bzip2/bzip2_1.0.6.bb +0 -0
index ed12277..d1d1c8d 100644
@@ -17,6 +17,7 @@ SRC_URI[md5sum] = "00b516f4704d4a7cb50a1d97e6e8e15b"

SRC_URI[sha256sum] = "a2848f34fcd5d6cf47def00461fcb528a0484d8edef8208d6d2e2909dc61d9cd"

Quoted 4 lines
Quoted 2 lines

PACKAGES =+ "libbz2 libbz2-dev libbz2-staticdev"
+PACKAGES_remove = "bzip2-dev bzip2-staticdev”

why remove ${PN}-dev ? others should be removed IMO

I think that it had added libbz2-dev was because debian/ubuntu uses libbz2-dev, the similar to xz.

// Robert

Quoted 24 lines
Quoted 21 lines

CFLAGS_append = " -fPIC -fpic -Winline -fno-strength-reduce -D_FILE_OFFSET_BITS=64"

meta/recipes-extended/bzip2/bzip2_1.0.6.bb +0 -0
@@ -35,7 +36,7 @@ do_install_ptest () {
 

FILES_libbz2 = "${libdir}/lib*${SOLIBS}"

meta/recipes-extended/bzip2/bzip2_1.0.6.bb +1 -1
-FILES_libbz2-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV}"
+FILES_libbz2-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/lib*.la"

SECTION_libbz2-dev = "devel"
RDEPENDS_libbz2-dev = "libbz2 (= ${EXTENDPKGV})"

--
1.7.9.5

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#5 lore raw

Re: [RFC PATCH 2/2] bzip2: remove bzip2-dev from PACKAGES

Quoted 24 lines · Robert Yang
Quoted 18 lines · Khem Raj
Quoted 18 lines · Robert Yang

There should be only one dev package which is libbz2-dev, so remove bzip2-dev.

---
meta/recipes-extended/bzip2/bzip2_1.0.6.bb | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes-extended/bzip2/bzip2_1.0.6.bb +0 -0
index ed12277..d1d1c8d 100644
@@ -17,6 +17,7 @@ SRC_URI[md5sum] = "00b516f4704d4a7cb50a1d97e6e8e15b"

SRC_URI[sha256sum] = "a2848f34fcd5d6cf47def00461fcb528a0484d8edef8208d6d2e2909dc61d9cd"

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

PACKAGES =+ "libbz2 libbz2-dev libbz2-staticdev"
+PACKAGES_remove = "bzip2-dev bzip2-staticdev”

why remove ${PN}-dev ? others should be removed IMO

I think that it had added libbz2-dev was because debian/ubuntu uses libbz2-dev, the similar to xz.

we have rpm and opkg hats as well.

#6 lore raw

Re: [RFC PATCH 2/2] bzip2: remove bzip2-dev from PACKAGES

Quoted 30 lines · Khem Raj
Quoted 30 lines · Robert Yang
Quoted 22 lines · Khem Raj
Quoted 18 lines · Robert Yang

There should be only one dev package which is libbz2-dev, so remove bzip2-dev.

---
meta/recipes-extended/bzip2/bzip2_1.0.6.bb | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes-extended/bzip2/bzip2_1.0.6.bb +0 -0
index ed12277..d1d1c8d 100644
@@ -17,6 +17,7 @@ SRC_URI[md5sum] = "00b516f4704d4a7cb50a1d97e6e8e15b"

SRC_URI[sha256sum] = "a2848f34fcd5d6cf47def00461fcb528a0484d8edef8208d6d2e2909dc61d9cd"

Quoted 2 lines

PACKAGES =+ "libbz2 libbz2-dev libbz2-staticdev"
+PACKAGES_remove = "bzip2-dev bzip2-staticdev”

why remove ${PN}-dev ? others should be removed IMO

Quoted 4 lines
Quoted 2 lines

I think that it had added libbz2-dev was because debian/ubuntu uses libbz2-dev, the similar to xz.

we have rpm and opkg hats as well.

OK, I will remove libbz2-dev as you and RP preferred.

// Robert

Quoted 3 lines
#7 lore raw
In reply to Robert Yang
Quoted 7 lines · Robert Yang

Hello,

I think that one recipe should only have one -dev package, I'm not sure whether this is right or not, please feel free to give your comments, we still have about 30 recipes in oe-core which have more than one dev packages, more info:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7481

I'd much prefer that ${PN}-dev was the dev package rather than the way round that this patch series has things...

Cheers,

Richard

#8 lore raw
In reply to Robert Yang
Quoted 4 lines · Robert Yang

Hello,

I think that one recipe should only have one -dev package, I'm not sure whether this is right or not, please feel free to give your comments, we

I know it is already 1 year since this change. But I can't seem to find any discussion or any explanation to why this change was required and what specific problem it was supposed to fix. Please point me to a clear reasoning of this change. Thanks.

Signature · 1 line
Denys
Quoted 31 lines

still have about 30 recipes in oe-core which have more than one dev packages, more info:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7481

// Robert

The following changes since commit fbaddd724855a829698d853a70eee86118d6a5e7:

  package_manager: call createrepo with --dbpath pointing inside WORKDIR (2015-04-02 12:00:55 +0100)

are available in the git repository at:

git://git.openembedded.org/openembedded-core-contrib rbt/dev
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/dev

Robert Yang (2):
xz: remove xz-dev from PACKAGES
bzip2: remove bzip2-dev from PACKAGES

 meta/recipes-extended/bzip2/bzip2_1.0.6.bb |    3 ++-
 meta/recipes-extended/xz/xz_5.2.0.bb       |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)
Signature · 7 lines
1.7.9.5

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
#9 lore raw
Quoted 10 lines · Denys Dmytriyenko
Quoted 4 lines · Robert Yang

Hello,

I think that one recipe should only have one -dev package, I'm not sure whether this is right or not, please feel free to give your comments, we

I know it is already 1 year since this change. But I can't seem to find any discussion or any explanation to why this change was required and what specific problem it was supposed to fix. Please point me to a clear reasoning of this change. Thanks.

There is only one source package, so there should be only one pack of header files, dev libs, and so on, and they should be placed in a uniq pkg.

// Robert

Quoted 1 line
#10 lore raw
Quoted 7 lines · Robert Yang
Quoted 6 lines · Denys Dmytriyenko
Quoted 4 lines · Robert Yang

Hello,

I think that one recipe should only have one -dev package, I'm not sure whether this is right or not, please feel free to give your comments, we

Quoted 7 lines
Quoted 4 lines

I know it is already 1 year since this change. But I can't seem to find any discussion or any explanation to why this change was required and what specific problem it was supposed to fix. Please point me to a clear reasoning of this change. Thanks.

There is only one source package, so there should be only one pack of header files, dev libs, and so on, and they should be placed in a uniq pkg.

Since you are using "should" twice in the same sentence, can you please point me to a ratified RFC?

Signature · 1 line
Denys
#11 lore raw
Quoted 18 lines · Denys Dmytriyenko
Quoted 17 lines · Robert Yang
Quoted 15 lines · Denys Dmytriyenko
Quoted 6 lines · Robert Yang

Hello,

I think that one recipe should only have one -dev package, I'm not sure
whether this is right or not, please feel free to give your comments, we

I know it is already 1 year since this change. But I can't seem to find any
discussion or any explanation to why this change was required and what
specific problem it was supposed to fix. Please point me to a clear reasoning
of this change. Thanks.

Quoted 8 lines
Quoted 4 lines

There is only one source package, so there should be only one pack of header
files, dev libs, and so on, and they should be placed in a uniq pkg.

Since you are using "should" twice in the same sentence, can you please point
me to a ratified RFC?

I couldn't seem to see the history of this discussion in my mail folder but I do remember some patches along these lines.

The reason for a single -dev package is that the "package chain" functions we have assumes this. I know there are some specific cases where we do have multiple -dev packages (qt4, gcc-runtime) but they are very much in the minority and are special cases.

I'm definitely on record as saying the depchains code needs revisiting and redoing, preferably with a structured rethink so that we can better handle situations like this. Until that is done, multiple -dev packages can cause issues and we did remove some where there didn't seem to be any real benefit.

Which case is causing problems for you?

Cheers,

Richard

#12 lore raw
Quoted 36 lines · Richard Purdie
Quoted 18 lines · Denys Dmytriyenko
Quoted 17 lines · Robert Yang
Quoted 15 lines · Denys Dmytriyenko
Quoted 6 lines · Robert Yang

Hello,

I think that one recipe should only have one -dev package, I'm not sure
whether this is right or not, please feel free to give your comments, we

I know it is already 1 year since this change. But I can't seem to find any
discussion or any explanation to why this change was required and what
specific problem it was supposed to fix. Please point me to a clear reasoning
of this change. Thanks.

Quoted 8 lines
Quoted 4 lines

There is only one source package, so there should be only one pack of header
files, dev libs, and so on, and they should be placed in a uniq pkg.

Since you are using "should" twice in the same sentence, can you please point
me to a ratified RFC?

I couldn't seem to see the history of this discussion in my mail folder but I do remember some patches along these lines.

The reason for a single -dev package is that the "package chain" functions we have assumes this. I know there are some specific cases where we do have multiple -dev packages (qt4, gcc-runtime) but they are very much in the minority and are special cases.

Quoted 7 lines

I'm definitely on record as saying the depchains code needs revisiting and redoing, preferably with a structured rethink so that we can better handle situations like this. Until that is done, multiple -dev packages can cause issues and we did remove some where there didn't seem to be any real benefit.

Which case is causing problems for you?

Thanks, Richard.

I was updating some of our old recipes to work with the latest code and had to replace dependencies on libblah-dev to blah-dev as well as -staticdev and -dbg in several places. When tried to dig up any relevant discussion on this matter either as a discussion or clear explanation of the problem this causes, I couldn't find any, hence my inquiry.

Signature · 1 line
Denys
#13 lore raw
Quoted 45 lines · Denys Dmytriyenko
Quoted 36 lines · Richard Purdie
Quoted 18 lines · Denys Dmytriyenko
Quoted 17 lines · Robert Yang
Quoted 15 lines · Denys Dmytriyenko
Quoted 6 lines · Robert Yang

Hello,

I think that one recipe should only have one -dev package, I'm not sure
whether this is right or not, please feel free to give your comments, we

I know it is already 1 year since this change. But I can't seem to find any
discussion or any explanation to why this change was required and what
specific problem it was supposed to fix. Please point me to a clear reasoning
of this change. Thanks.

Quoted 8 lines
Quoted 4 lines

There is only one source package, so there should be only one pack of header
files, dev libs, and so on, and they should be placed in a uniq pkg.

Since you are using "should" twice in the same sentence, can you please point
me to a ratified RFC?

I couldn't seem to see the history of this discussion in my mail folder but I do remember some patches along these lines.

The reason for a single -dev package is that the "package chain" functions we have assumes this. I know there are some specific cases where we do have multiple -dev packages (qt4, gcc-runtime) but they are very much in the minority and are special cases.

Quoted 7 lines

I'm definitely on record as saying the depchains code needs revisiting and redoing, preferably with a structured rethink so that we can better handle situations like this. Until that is done, multiple -dev packages can cause issues and we did remove some where there didn't seem to be any real benefit.

Which case is causing problems for you?

Quoted 8 lines

Thanks, Richard.

I was updating some of our old recipes to work with the latest code and had to replace dependencies on libblah-dev to blah-dev as well as -staticdev and -dbg in several places. When tried to dig up any relevant discussion on this matter either as a discussion or clear explanation of the problem this causes, I couldn't find any, hence my inquiry.

You might have been thinking about my problems with -dbg packaging that currently breaks a number of dependencies. Bug #9104

Signature · 4 lines
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
#14 lore raw
Quoted 55 lines · Gary Thomas
Quoted 45 lines · Denys Dmytriyenko
Quoted 36 lines · Richard Purdie
Quoted 18 lines · Denys Dmytriyenko
Quoted 17 lines · Robert Yang
Quoted 15 lines · Denys Dmytriyenko
Quoted 6 lines · Robert Yang

Hello,

I think that one recipe should only have one -dev package, I'm not sure
whether this is right or not, please feel free to give your comments, we

I know it is already 1 year since this change. But I can't seem to find any
discussion or any explanation to why this change was required and what
specific problem it was supposed to fix. Please point me to a clear reasoning
of this change. Thanks.

Quoted 8 lines
Quoted 4 lines

There is only one source package, so there should be only one pack of header
files, dev libs, and so on, and they should be placed in a uniq pkg.

Since you are using "should" twice in the same sentence, can you please point
me to a ratified RFC?

I couldn't seem to see the history of this discussion in my mail folder but I do remember some patches along these lines.

The reason for a single -dev package is that the "package chain" functions we have assumes this. I know there are some specific cases where we do have multiple -dev packages (qt4, gcc-runtime) but they are very much in the minority and are special cases.

Quoted 7 lines

I'm definitely on record as saying the depchains code needs revisiting and redoing, preferably with a structured rethink so that we can better handle situations like this. Until that is done, multiple -dev packages can cause issues and we did remove some where there didn't seem to be any real benefit.

Which case is causing problems for you?

Quoted 8 lines

Thanks, Richard.

I was updating some of our old recipes to work with the latest code and had to replace dependencies on libblah-dev to blah-dev as well as -staticdev and -dbg in several places. When tried to dig up any relevant discussion on this matter either as a discussion or clear explanation of the problem this causes, I couldn't find any, hence my inquiry.

Quoted 2 lines

You might have been thinking about my problems with -dbg packaging that currently breaks a number of dependencies. Bug #9104

So, why -dbg cannot follow the example of -dev and -staticdev packages? I.e. in your ffmpeg example it would mean creating all the necessary libblah-dbg packages. Why isn't it the option?

Signature · 1 line
Denys
#15 lore raw
Quoted 5 lines · Denys Dmytriyenko

So, why -dbg cannot follow the example of -dev and -staticdev packages? I.e.
in your ffmpeg example it would mean creating all the necessary libblah-dbg packages. Why isn't it the option?

To save time and effort the debug packaging happens automatically in modern OE, so it's actually effort to split the debug files into multiple packages. If you split the packaging from PN-dbg to libfoo-dbg libbar-dbg, where does the debug source go? There's even more packages to follow the dependencies for now too.

As much as I'd like to see 9104 disappear (being the assignee for it), I do think that supporting a single -dbg package is the right thing to do.

Ross