Bug#90664: How's the foomatic package for Debian going?
On Thu, Nov 29, 2001 at 02:24:07PM -0500, Grant Taylor wrote:
> >>>>> Jeff Licquia <licquia@debian.org> writes:
> > I take it you'd be interested in a patch that does the right thing?
> > I'll look to see how hard that would be.
>
> Yes, of course. Manfred has submitted a number of patches, which go
> right in.
He also appears to have spoken up. I will respect his ITP if he gets
a package into shape *now* and sends it on; the reason he hasn't
uploaded yet is that he's still going through the new maintainer
process. But he needs to do the heavy lifting, and soon.
In that case, all of this might be moot. But oh well. (Manfred, if
you're interested in any of this, let me know and I'll tell you how to
do it.)
> You're actually welcome (nee encouraged) to put the debian/ stuff into
> our CVS. (Till, put your spec in!). We're also hoping to accumulate
> any GUI tools in it as well.
That's not a problem - mostly.
The one sticking point is the Debian changelog. This file isn't just
documentation; it is the source of the package version, and
maintaining it properly is crucial for ensuring that the famous Debian
upgrade system works properly.
The problem that we see is that, when the Debian changelog is part of
upstream CVS, people will inevitably build packages with CVS.
However, during development cycles, the changelog will inevitably get
out of date. This will mean that packages built out of CVS will end
up with the same version as the "released" packages; this makes apt
unhappy, and will in some cases cause apt to install older packages
over the shiny new CVS packages.
This has been the cause of some heated debate within the project. The
upshot is that there isn't a good solution to this problem that meets
all the necessary criteria. However, I think we can avoid these
problems with careful coordination between upstream and Debian
maintainers. In particular, we could do something like this:
- At midnight, a changelog entry could be tacked on and checked in
automatically by the script that creates your nightly snapshots.
This could be versioned with the current date and a Debian version
of "0.1".
- After the snapshots are built, another entry could be added to CVS,
with a date and a version of "0.2". This would cover packages
built by third parties from a direct CVS checkout.
- On those (comparatively) rare occasions that an official upload is
done, the two automatic entries would be removed and a real
changelog entry, with a version numbered "-1" (as usual), would be
added and used for the build. Future versioning for a particular
day would follow Debian norms.
- Before the next run, the previous day's changelog entries would be
removed (except for any official ones), to keep the changelog from
infinite growth.
In this scheme, official packages would automatically trump unofficial
ones from the same day, and CVS checkouts mid-day would trump the
nightly snapshot from that day (but not other checkouts; that's just
too hard). People who wanted to be on the bleeding edge could add an
apt repository to their sources.list, and admins wouldn't have to
worry about custom-built third-party packages.
The main problem with this is that the upstream people have to commit
to helping maintain a scheme like this to really make it work. So, I
ask you: does this sound doable?
> > Cool. The major issue there is "conffile sanctity"; packages are
> > forbidden by policy to mess with registered configuration files except
> > through very tightly-controlled interfaces. (Not all configuration
> > files have to be registered, though; for details - and a good sleep aid
> > - check out the Debian policy manual.)
> >
> > I can tell you for certain that the cupsys maintainer won't mind
> > accomodating. :-) For the other spoolers, I'll have to see how they
> > manage their printer configs. /etc/printcap, in particular, is looking
> > like a potential hot spot for trouble.
>
> Yes, this is a general issue. The original printcap code I wrote went
> to great pains to not molest existing printcap data while still
> letting you do some operations on it. This is different from, say,
> the new redhat thing where the printcap is merely a generated interim
> config file. To the extent that it doesn't disturb existing
> configuration, foomatic fits with the intent of policy, but not the
> letter. OTOH, to the extent that I didn't write all the code and
> don't trust even the parts I *did* write, I wouldn't count on it not
> scrambling someone someday ;(
Well, I've done a little more research, and it turns out that
/etc/printcap is a registered conffile - by lprng only. I'm fairly
sure that there's an interface to modify it, though, as the
magicfilter package does that at least.
We'd therefore have some latitude to play with /etc/printcap as long
as lprng isn't installed. We still have to be careful how we handle
user data, but Debian places much less stringent guarantees down;
screwing up might result in a high-priority bug, but it wouldn't be
grounds for whacking me over the head with policy, and we'd have
options besides "remove that behavior, now!" In the case of lprng,
since there's most likely a defined interface to modify /etc/printcap,
we're in even better shape, since errors in modification would most
likely be bugs against lprng, not foomatic.
Of the other print spoolers, neither gnulpr nor lpr register
/etc/printcap. I elected not to make /etc/cups/printers.conf a
conffile for cupsys, which means that foomatic should be able to
modify it more or less with abandon. (cupsys-bsd installs
/etc/printcap as a symlink to /etc/printcap.cups, which is generated
from printers.conf.) I have no idea how pdq is laid out.
More later, maybe. Disney World is too tiring. :-)
Reply to: