On Thu, Nov 29, 2001 at 02:24:07PM -0500, Grant Taylor wrote: > >>>>> Jeff Licquia <[EMAIL PROTECTED]> 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. :-)
