Web lists-archives.com

Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")




>>>>> "Marco" == Marco d'Itri <md@xxxxxxxx> writes:

    Marco> On Apr 15, Sam Hartman <hartmans@xxxxxxxxxx> wrote:
    >> However if my sources are in git, git is the definitive format
    >> for thinking about things, and the dsc I'm producing is only for
    >> the convenience of the archive, I don't want to deal with an
    >> upstream tarball.
    Marco> Generating an upstream tarball in this case is still useful
    Marco> because this way we do not need to upload and store forever
    Marco> the full source archive every time that something changes
    Marco> only in the packaging.

How important is this in practice, and at what size package does this
become  a real issue.

It seems that it depends on:

* Source being some significant fraction of the binary size

* The  package being large enough this matters

* The package getting differences in packaging that do not involve
  changes outside of packages  often enough.  Remember that for the
  packages we're talking about here, any change to things outside of
  debian would count as a new upstream

I agree that 20 years ago when I started in Debian this was a real issue
for a lot of packages.

My strong suspicion now is that we would be better off making things
easier for our developers than focusing on what I think is a relatively
unimportant disk space savings.
There are doubtless a fewt packages that are really large and that do
tend to get package-only changes often where the upstream split makes
sense.

However, I think for a lot of packages we're better off making it easier
for developers and trying to get pushing a package update into something
where it can fit into a smaller time slice that gets serviced more often
than something that takes a large chunk of time.

--Sam