Re: Apt repository interoperability (was: Bug#311188: Debian edu messed up my Ubuntu system.)
On Fri, Apr 25, 2008 at 08:48:02PM +0200, Raphael Hertzog wrote:
> On Fri, 25 Apr 2008, Matt Zimmerman wrote:
> > Because quite a few different distributions use APT and .deb repositories,
> > and their packages aren't necessarily interchangeable, it would be useful if
> > APT knew which distribution you were running and checked this against the
> > Release file in the repository. This would make it possible to display a
> > warning or otherwise behave intelligently.
> > This idea has been around for a while. There is real work associated with
> > doing this, however, and it hasn't yet been a big enough priority for anyone
> > with the necessary time and skills.
> I'd like to note that the dpkg team has some plans that covers part of
> this problematic. Guillem has written down some preliminary ideas here:
> The idea is to have "base-files" provide the name of the current
> distributon. This distribution name would then be propagated to
> the Origin: field in debs built in the system.
> (I think the part about changelog handling needs more thought however)
Thanks for this. I generally like the idea of using Origin here (hey,
might as well use it for something!), though I agree that changelog
handling is not quite right here. Some specific comments:
# * Changing Maintainer when source changes are done on a derivative.
# - There was an informal vote for that already in Debian, and Ubuntu is
# changing the 'Maintainer|Uploader' field for that, and preserving
# the originl ones as 'Original-(Maintainer|Uploader):'.
We don't currently change Uploader, although perhaps we should (so that
it could be used informationally to designate people with substantial
knowledge about the package).
# devscripts (dch and other tools) would be modified to insert the current
# origin in a new field in the changelog file header (origin=foo), for
# each new revision.
# This allows to fork a package for a derivative of a given origin, and keep
# track of the specific derivative changes.
This seems rather verbose, and we haven't been running into problems due
to the lack of this to my knowledge. Are the current schemes (version
number changes, upload target changes) not enough?
# The bug closures are specific to a distribution, and the upload is as well
# so it makes sense to bind the Closes field to those changelog entries
# specific to the target origin distribution. dpkg-dev would be changed to
# only output Closes fields if the changelog origin matches the current
# distro origin (in case a derived distro upload a source package w/o
At the moment, it's rather useful that when committing changes upstream
in response to Ubuntu bugs we can put "LP: #nnnnnn" in debian/changelog
and have it automatically close the Ubuntu bugs once it's synced or
merged into Ubuntu. This is working very well for us now.
Of course, we could carry on doing that with dpkg modifications, but I
can't help feeling that it would be worthwhile to support this more
generally somehow. That said I can see why you'd want to suppress the
Closes: field in .changes for non-Debian distributions, in case of
incautious archive setups.
# When importing a new release from one distro to another not always the
# first version is taken (2.5-1 or similar), and the current tools do not
# include the tarball. This would be changed to analyze the changelog and
# include a tarball whenever the previous changelog entry to the current
# upload has a different upstream part or a different origin.
Ah, I suppose this explains why you want to put the origin in the
changelog. That said you could achieve something similar just by
comparing upload targets; worst case you'd occasionally upload a
duplicate .orig.tar.gz and the archive would have to throw it away, or
maintainers of packages with enormous .orig.tar.gz files could override
with -sd. I suppose that's not quite as accurate but would save having
to change the changelog format and deal with people not having
up-to-date devscripts or not using devscripts at all.
Colin Watson [firstname.lastname@example.org]