Re: How to deal with "assets" packages shadowing real upstream
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Mar 09, 2016 at 11:37:12AM +0100, IOhannes m zmölnig (Debian/GNU) wrote:
> i think that §4.13 does not cover the original issue of jonas at all, as
> it's about something different: using convenience copies instead of the
> system provided packages.
>
> the case being discussed is (i believe):
> - upstream releases of "foo" contain a component "bar"
Technically this is true, but the important part is that "bar" is not just a
component, but one that is separately released.
If the "real" source of a library is bundled with some binary, they should be
in the same source package as well. 4.13 is about components that upstream
downloaded from somewhere and copied into their source tree.
Since they only have a copy, the real upstream will always be more up to date.
Also, if Debian finds a security problem, we send it back to our upstream and
we want that to be the real upstream, not just a copy which is used by only a
part of the community.
> - "bar" is not an *integral* part of "foo" (it's a dependency)
I think you mean here what I wrote above, correct?
> - nobody has packaged "bar" yet
>
> - may the packaging of "foo" then rely on the included "bar", or do we
> have first have to package a standalone release of "bar"?
>
>
> i don't think that there is anything inherently wrong using the included
> "bar".
Yes, there is. It doesn't mean it's not allowed. As 4.13 says, it *shouldn't*
be done. If there's a good reason (and "getting the software into Debian with
the limited time I have for packaging it" can be a good reason IMO), it is
acceptable to deviate from such a rule. But it is wrong, should be fixed and
deserves a bug report.
> esp. if the packager actually does split the "bar" component into a
> separate binary package so it's usable by other packages as well.
The main reason that is better is that it makes it easier to transition to the
correct situation.
> actually, i think in some cases it's even the better approach...think of
> all that tiny js packages; wouldn't everybody be happy if they were
> accumulated into a bigger upstream, even if this upstream was just a
> proxy to the "real" upstreams?
No, that wouldn't make me happier. I think it would be acceptable, but I would
prefer to have one source package per upstream release. So if an author
bundles several of their libraries in one release, that should be one source
package (but may still be multiple binary packages, if that makes sense). But
if the libraries are released separately by their authors, they should be
separate source packages.
Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJW4HMRAAoJEJzRfVgHwHE6Q+UQAJTn4Ib9TK3VVfqqNe8z49lC
I8ba3y12luTjGIXzTSCxExo3IDCAmRlG4+/6VOA/js57r27hIi39V1n+QCrbJ0I1
gMQ/qYFrEn9BZnJkkbMgb/5gc3jhMX5wj2xuO6OdecCosKKqU8QwP0pEDl1Lc1BS
0LcRW7vLZbau0oskMroMyQeeslaJ9FZO/mi5bgaVCVSSx9kM4Zb0fpjAHmvjWb2q
EtTAm342kVZwhEg2Yk0GpI9XNVsV+kcUdb+JHvsB0XUHXIPvQLIfaqWMCxYl3I3K
JbHePmHWj0oVyxE3YJ2EL/mlyo3qaeWnnJbHzREN26N9xy39tC1xdhMGqXxSy232
LL0y0cSQw7WJBKq1m3QtzgNmcZMSKfci4h9nXn09/9lGH/c8y41+tkoM//6SQd14
swr4NobTLxIstaGR+jCDYwI58j/sntetqQiPUxKQk9aaKUUd/QmBs1rwVgHH8Gy6
0EDcKkhi7t6C0kN4ZSYqqYyxo2HtamTPubYFlOPq4vP5NgXs6iSHexXSIUL0cfhy
HJsJWLcdkSxUu0XvDcQdhFncZSVjWXx2nPBxOg3PFNXYJUMj0rUBbj4voXQ5Atna
MJvZPPdVWY8beQDGOr+3Q1vwXNsZCYYu34lqcokvolrwXE9M/Ltw4DyoMNzGOlSb
a1SyFqpEkcNux4VIcn0Y
=SXtk
-----END PGP SIGNATURE-----
Reply to: