[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to deal with "assets" packages shadowing real upstream



Quoting Bas Wijnen (2016-02-26 20:16:32)
> On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote:
>> Do we favor tracking the true upstreams when packaging for Debian?
>
> There was some discussion about this on the list recently, but this is 
> a question that didn't really come up, AFAIK.
>
> IMO, there are two things that matter here:
> 1. We require source.  If the "fake" upstream does not provide that, 
>    it is certainly not adequate.  IIUC, this is your situation (but I 
>    didn't check your links).  That is: minified js is not source, and 
>    a project including it in its distribution is equivalent to a 
>    compiled project including a static library.  In both cases, the 
>    code must be packaged from its source, and the bundled version must 
>    be discarded.  This was discussed, and AFAIK what I wrote here is 
>    what most (but not all) people agreed with.

Above is *not* the issue I ask about here: We may disagree on how we 
should interpret them, but rules _do_ exist in Policy.

It is below that I ask about here:

> 2. Needless forking is bad.  There is no consent on what is "needless" 
>    though. My point is that having multiple copies of a thing that are 
>    all treated as source leads to problems.  In Debian, we recognize 
>    that and one effect of that is that we don't want bundled libraries 
>    in packages.  In the greater free software community, not everyone 
>    sees it this way.  Having this opinion in Debian, I think we should 
>    use our influence to try to push upstreams the right way.  That 
>    means we should package real upstream if there are multiple sources 
>    to choose from.  Another reason for doing this is that future code 
>    duplication in Debian is automatically prevented.  In your example: 
>    if someone needs the serverside version of the package, they would 
>    package node-handlebars and then we have two versions of the code 
>    in Debian.  If the real upstream was used to begin with, that 
>    problem would have been avoided.

Right.  That is the issue.  Question I raise is how to deal with it?

I agree with you that the real upstream should be used when possible - 
but is that just the personal opinion of two Debian developers which 
should not be imposed on others (read: at most file wishlist bugreports) 
or do we have rough consensus in Debian to make it into Policy, so that 
issues of that kind can be treated as more severe bugs?


 - Jonas

P.S. (The concrete case had the additional oddity that the real upstream 
_was_ used to begin with but later abandoned as less convenient.)

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


Reply to: