Re: CVS location for dselect documentation for beginners
On Sun, Dec 08, 2002 at 04:15:47PM -0600, Adam DiCarlo wrote:
> > If it goes in with dpkg, then we have a whole new set of arrangements to
> > make with the dpkg developers in order to accept the document, to have
> > others work on it, translate it, etc. I'd very much like to avoid that.
>
> Well, it's actually far less work for the DDP since it takes the
> burden off us to maintain it. I would think it just depends on
> whether these guys want to maintain it (which I would doubt) and if
> so, it is probalby pretty much up to them to accept the documents and
> work with contributors.
Yeah, but the dpkg tree isn't open to commits to all developers, like the
DDP tree is. Besides, I'm not sure Wichert will be amenable to putting the
beginners guide into the dselect package...
I think that just like the APT HOWTO, it's better off among the other docs,
it's just less hassle with the maintainers of the code itself.
> > > If in the DDP CVS area, should it be packaged as well? I think it will
> > > need to be...
> >
> > It can be packaged from there too, I don't see how that would necessarily
> > impede the packaging process.
>
> No, it's just more work to be done is all....
Is it packaged anywhere now?
(install-doc perhaps? Last I checked, install-doc was entirely broken. :)
> > > > I'm thinking of moving it out into the DDP tree where it will likely get
> > > > some more attention and tender loving care ;) Any suggestions for preserving
> > > > the history? cp the ,v files, or just ignore that and cvs remove here + cvs
> > > > add there, with a pointer to the old place just in case anyone cares?
> > >
> > > I would suggest doing a checkout from the head, then copy those files
> > > over and do a CVS import from that, then start adapting it for being
> > > stand-alone.
> >
> > Right, so losing the history? Or does cvs import do something special to
> > preserve history?
>
> No, you would lose the history. But so what? Or rather, if you
> wanted the history, you'd go to the boot-floppies package. Why have
> the history in two places, eh?
OK.
> > > > The situation is similar with the release notes, which just need a few
> > > > tags to be able to skip some info for architectures recently released.
> > >
> > > Yes, ditto.
> >
> > The FAQ needs a similar set of information so we could even keep this in the
> > parent directory of the manuals tree and share it.
>
> That is going to get a bit tricky if you are providing these as source
> packages.
I figured we can easily hack it with a bit of symlink creation in the
makefiles.
> What I would suggest doing as an alternative is to create a
> 'common-deb-data' CVS module, and via the CVS modules functionality,
> including this module with the various CVS modules that use it, e.g.,
> the FAQ etc. This would effectively do:
>
> CVS checked out appearance Repository location
> -------------------------- ---------------------------------
> faq/ -> ddp/manuals.sgml/faq
> faq/common-deb-data/ -> ddp/manuals.sgml/common-deb-data
>
> install/ -> ddp/manuals.sgml/install
> install/common-deb-data/ -> ddp/manuals.sgml/common-deb-data
Interesting. I didn't know one could do that.
> > The set of makefiles would also be much simpler if it the installation
> > manual was standalone and worked with the variables from its own files
> > instead of working with other files like it does now. Given the past
> > recurring headaches we had with the build system, this is a big bonus :)
>
> I completely agree. The old system is rather overcomplex as well.
>
> In fact, there are even deeper issues. Are we happy with the way
> we're using SGML conditional inclusion for porter stuff? Aren't we
> rather annoyed with the difficulty in validating that and the
> complexity it presents to authors? Should we move to another means of
> marking up arch-specific sections? If we were using DocBook, we could
> use (pretty naturally) the 'arch' attribute on <para>, <phrase>, and
> <section>, and then handle the presentation issues (should we have one
> manual with arch-specific stuff simply styled/presented in a certain
> way? or one manual per arch as we have now?) in stylesheets.
Yeah, I never did fancy the raw and inflexible nature of the conditionals in
ddoc-sgml, it's just dumb at times.
Then again, it's not going to be a major issue for sarge as we'll likely
need less of that stuff because less architectures will be newly released
with it. woody was pretty special in this regard. Yay for woody! :) I don't
say that often enough...
--
2. That which causes joy or happiness.
Reply to: