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

Bug#904302: Whether vendor-specific patch series should be permitted in the archive



On Fri, Oct 05, 2018 at 08:49:47AM +0200, Philip Hands wrote:
> Adrian Bunk <bunk@debian.org> writes:
> 
> > On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote:
> >>...
> >> IMO policy should recomend the use of separate source packages as the
> >> prefered solution to the problem that vendor-specific patch series were
> >> supposed to address.
> >
> > In this case please make an explicit decision on whether build-time 
> > patching is the recommended replacement for vendor-specific patch 
> > series, or what kinds of build-time patching will no longer be 
> > permitted.
> >
> > The current situation in the archive is:
> > - 18 packages with vendor-specific patch series
> > - an unknown number of packages (e.g. src:gcc-8) that are doing 
> >   vendor-specific build-time patching and/or patching based on
> >   other factors like architecture
> > - > 100 packages that are doing patching and/or configuration
> >   based on dpkg-vendor
> > - an unknown number of packages (e.g. src:gcc-8) that are doing patching 
> >   and/or configuration based on other tools like lsb_release
> >
> > It is not clear at all which of the above exactly you want to have 
> > removed from the archive and moved as permanent deltas downstream.
> 
> I think it's entirely up to the maintainers of the package (as long as
> they avoid vendor-specific patch series in future).
> 
> However if someone reads the prohibition against vendor-specific patch
> series, and is left wondering what is the best way to deal with this
> situation, then it would probably be helpful to give them a hint.
> 
> The methods you highlight all seem to suffer from the problem that if a
> downstream needs to make a vendor specific change, they need to do an
> odd dance where they may have to introduce a delta in order to get the
> vendor version out in a timely manner, then they need to get that into
> the debian source, and perhaps prompt a no-change release of the Debian
> package in order to be able to pick up the change and drop the delta.

This sounds like a very negative description of the standard
Open Source mantra "try to get all your changes upstream".

> It makes much more sense to me to have branches for the debian and
> downstream patches side-by-side in one's favourite source control system,
> and just build and release whatever one needs, whenever one needs it.
>...

Sometimes Debian and downstream maintainer are the same person.

Usually they are not, and then your suggestion won't work.

One common case is Ubuntu requiring different configuration of some 
packages, to avoid dependencies of security supported packages in
Ubuntu on packages that are not security supported in Ubuntu.

The fundamental reason for the existence of Raspbian is a vendor 
specific difference in all gcc packages. There are also other
packages in Debian that require different configuration for
the lower baseline.

The official source in the archive for a Debian package is the source 
tarball, which implies that any general solution used by downstreams
has to be based on the sources in these official tarballs.

> Cheers, Phil.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


Reply to: