Re: CVS directories in debian packages
Hi
On Sat, May 18, 2002 at 08:47:35PM -0500, Manoj Srivastava wrote:
> >>"Ola" == Ola Lundqvist <opal@debian.org> writes:
>
> Ola> On Fri, May 17, 2002 at 11:01:21PM -0500, Manoj Srivastava wrote:
> >> It does not make sense for source packages either; CVS
> >> directories in source trees cause havoc when trying to later import
> >> the sources into another CVS repository (for example, a user trying
> >> to keep local modifications of debian sources in a local CVS).
>
> Ola> Well you assume that all source packages are from an external
> Ola> upstream. That is not always the case. In fact many of the
> Ola> packages I maintain (like java-common, harden etc) is generated
> Ola> from a cvs dir. It is very convenient. How can you exclude the
> Ola> CVS dirs from the source package then?
>
> *ALL* my packages come from local CVS, including the one I am
> upstream on, None of them contain CVS dirs. Indeed, saying you are
> keeping sources in CVS is no excuse for not following guidelines laid
> out in CVS docs, even.
I can understand that as you are the cvs-buildpackage maintainer.
> Ola> Well I can export on every build but that takes quite a lot of time.
> Ola> I like to build from the normal cvs dir.
>
>
>
> I have not found that to be the case. cvs-buildpackage takes
> marginally more time than dpkg-buildpackage, but not perceptibly so.
Well you have to tag each release in the cvs for cvs-buildpackage to
work. Yes I could automate that. I used to with the orm package
(that I wrote for such situations) but I asked for its removal becuase
it was outdated. Maybe I have to start develop it again.
Brian> In which case, there isn't much you can do about these included CVS
Brian> files, in the source code. Especially if you don't have write access to
Brian> the upstream package.
That is also a issue in some cases. In many cases I have upstream write
access but not always. That is the case for mcal (for example). In that
case the cvs version is the version that upstream recommends but they
can not release a new one (because of verarious reasons I will not mention
here).
Brian> You could:
Brian> * Use cvs-buildpackage, but then all your local Debian changes
Brian> go out the window.
Brian> * Delete CVS directories, but then you can't update.
This can be a important factor.
Brian> * Import everything into your own CVS repository, but this adds
Brian> complexity not always required.
Agreed.
Brian> * The current woody version of dpkg-source seems to ignore these
Brian> files anyway...
Brian>
Brian> /usr/bin/dpkg-source:
Brian> [...]
Brian> $diff_ignore_default_regexp =
Brian> +'^.*~$|^\..*\.swp|DEADJOE|(?:/CVS|/RCS|/.deps)(?:$|/.*$)';
Brian> [...]
> Sounds like you are saying you are too lazy to do the right thing.
Take a look at the number of packages that I maintain and tell me that
I'm lazy again. If lazy <=> do not want unnecessary overhead, then yes
I'm lazy.
So I suggest the following two lintian checks.
* Error for binary packages that distribute CVS dirs.
* Warning for source packages that distribute CVS dirs.
Regards,
// Ola
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: