Joey Hess <[EMAIL PROTECTED]> writes:
> This is *not* a small problem. It is an epidemic. One package in 17 has the
> problem!
That is, less than 6% of packages.
> Packages exhibiting this problem, by md5sum of their long descriptions
> (note that this probably misses some that have long descrip
Joey Hess <[EMAIL PROTECTED]> writes:
> The long description is there for a reason, and I feel these packages are
> ignoring it it. The libc5 versions should explain, in detail, why you
> might want to install those packages over the non-libc5 versions. An extended
> description should be a hand-c
Joey Hess <[EMAIL PROTECTED]> writes:
> > 3.2.5. `debian/files'
> > Must not ship in a shipped source package
>
> I tend to disagree this needs to be in policy.
This should be in policy - it causes no end of problems for people doing
binary only recompilations on other archs.
>From the other
Roland Rosenfeld <[EMAIL PROTECTED]> writes:
> But this doesn't solve the other problem: dpkg -L shows these symlinks
> as real man pages. This is annoying at least for me...
dpkg is not a documentation browser, it is a package manager. It really
doesn't matter if dpkg -L shows symlinks or not,
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Roland> My intension was to get rid of these undocumented.7 symlinks, because
> Roland> they are quite useless because of the following points:
>
> Roland> a) dpkg -L shows that there is a man page, but there is
> only
> Roland>this useles
Joey Hess <[EMAIL PROTECTED]> writes:
> Joseph Carter wrote:
> > Maybe I'm missing something here (it wouldn't be the first time), but I
> > believe wichert said the changes in the non-us archive (ie, that non-us
> > is now a section of main, whether the archive happens to be on pandora or
> > on
Joey Hess <[EMAIL PROTECTED]> writes:
> I think you may be reading too much into the word "large". The complete
> paragaph:
>
> No large package (such as TeX and GNU Emacs) should use a direct
> subdirectory of /usr. Instead, there should be a subdirectory within
> /usr/lib (or /usr/local/
I forgot to Cc this to -policy, here is my reply:
> Santiago Vila <[EMAIL PROTECTED]> writes:
>
> > I think that a cross-compiler is not a "large" software package like the X
> > Window System.
>
> I agree. It also fits in with the goal of having /usr read only. The FSSTND
> also mentions the X
Guy Maor <[EMAIL PROTECTED]> writes:
> If our intent is that practically all systems install Standard and
> higher, do we really need four tiers there? Let's broaden important
> so it includes our current standard software and redefine standard as
> Ian suggested the new priority be defined.
I t
Ian Jackson <[EMAIL PROTECTED]> writes:
> OK, how about this: we rename (in a phased manner) Maintainer (in
> .changes) to Uploader. Also, we arrange for this new field to appear
> in the package control file, if it is different from Maintainer.
Yes, I agree with this as well.
Martin.
Jules Bean <[EMAIL PROTECTED]> writes:
> On 25 Feb 1999, James Troup wrote:
> >
> > > Giving the package maintainers more control over the overrides for
> > > their own packages seems a good strategy. Can you tell us why this
> > > approach was abandoned earlier?
> >
> > How about because a cer
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> You can innovate all you want -- as long as the old method in
> policy is supported (which you say you support). But you can't report
> bugs against packages for using the old method -- until you pass the
> new method (after it stabilizes) th
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > At all?? I think that dpkg-cross does a very reasonable job, and I've not
> > had to use any 'major hacks' to cross compile packages.
>
> I am talking about the debian/rules files. There is currently no way to
> write a good debian/rules files for
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Iff we agree that the packaging manual has the weight of
> Policy, I propose, as a purely packaging issue, to pull the two
> packages (not the documents -- the policy and the packaging manuals
> shall remain distinct documents). The policy m
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The only drawback I can see: If you do cross compilation, you can't easily
> run "debian/rules target" and expect it to work. You'd need to set the
> variables correctly.
That's already the case, even before your proposal.
> Currently, cross compila
Brederlow <[EMAIL PROTECTED]> writes:
> > I disagree. However would we compile a kernel without gcc and its
> > extensions?
> > IMO the default compiler for Debian should be the one Linus uses for the
> > kernel. This is currently gcc.
>
> I compiled and used egcc compiled kernels on my systems
Brederlow <[EMAIL PROTECTED]> writes:
> When considering poratibility and code cleaness, the only answere one
> can give to this question is "CC=cc".
>
> No sourcecode should rely on gcc or any of its extensions. And if it
> doesn`t use any gcc specific stuff, it should not rely on gcc.
I disagr
[EMAIL PROTECTED] (Ian Jackson) writes:
> The first case was dpkg, whose build system has been replaced with a
> fragile Byzantine monstrosity which depends on libtool and automake
> and is the source of several bug reports. Also, a directory was
> renamed without rhyme or reason ! I intend (whe
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 1. Package build process must be non-interactive
>
>
> This has been already presented to the list and had been accepted, but
> Christian did not have time to actually edit the file.
>
>
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 2.1. Change
> ---
>
> In general, Debian packages should use the same version numbers as the
> upstream sources.
>
> However, in some cases where the upstream version number is based on a
> date (e.g., a development `sna
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 1. Fixing of typo in packaging manual
> --
>
> This has been already presented to the list and had been accepted, but
> Christian did not have time to actually edit the file.
>
> At the bottom, it says
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 1. time stamps should be preserved
> --
>
> This has been already presented to the list and had been accepted, but
> Christian did not have time to actually edit the file.
>
> Most of our packages `tou
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 1. Bashism
> --
>
> The Debian Packaging Manual says:
>
> 12.2.4.1 If your package doesn't provide a shared library
>
>Put a call to dpkg-shlibs into your debian/rules file. If your package
>contains only binaries (e.g. no sc
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I agree, as well, but only for the root acoount. I have
> provided additional explanation in another message.
Yes, it doesn't make much sense for user accounts, which are not set up
in the base system. So should some text be included in policy
Steve Greenland <[EMAIL PROTECTED]> writes:
> The current base-files installs a default .profile and/or a default
> .bashrc in /root if there is no existing instance. I filed a bug, but
> the maintainer (Santiago Vila) closed it with the following message:
>
> > [explanation of why *snipped*] I b
<[EMAIL PROTECTED]> (Alex Yukhimets) writes:
> > Why? Does this tradition serve any purpose? Could it be that you want
> > it for non-free motif libraries?
>
> Is it a sin? :)
> I already gave some of the rationalization and I didn't mention motif.
No, not a sin - I was just trying to imagine wh
<[EMAIL PROTECTED]>(Alex Yukhimets) writes:
> > Sounds like a cool idea to me. Let's do it!
>
> Sorry, but NO!
>
> Let's do this experiments with Hurd, ok?
> There are some traditions of UNIX that I would hate to see broken.
Why? Does this tradition serve any purpose? Could it be that you want
Santiago Vila <[EMAIL PROTECTED]> writes:
> On 20 Aug 1998, Manoj Srivastava wrote:
>
> > Hi,
> > >>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
> >
> > Santiago> Maybe the right thing to do here, since none of the new
> > Santiago> lists did exist previously, and since debian-devel
Santiago Vila <[EMAIL PROTECTED]> writes:
> > I suggest one change to this. Instead of renaming debian-devel-changes
> > to debian-devel-changes-i386, it should be changed to
> > debian-devel-changes-source. This way people who upload source packages
> > for other architectures will get noticed, a
Santiago Vila <[EMAIL PROTECTED]> writes:
> Therefore, I will send the last proposal:
>
> http://www.debian.org/Lists-Archives/debian-policy-9808/msg00115.html
>
> to [EMAIL PROTECTED], so that whenever the new upload procedure is
> implemented, the list is splitted in the proposed way at that t
[EMAIL PROTECTED] (Adam P. Harris) writes:
> BTW, noticed grammar and spelling issue. "Light-weight" should by
> hypenated.
I'd say one word:
# ispell -a
@(#) International Ispell Version 3.1.20 10/10/95
lightweight
*
Martin.
Jules Bean <[EMAIL PROTECTED]> writes:
> > * GPG as standard signature for packages
> >
> > Marco d'Itri: probably GPG is not ready yet
>
> I understood the outcome of the last discussion here to be that it very
> nearly is. In particular, I'd like to note that GPG supports idea and rsa
> as
Guy Maor <[EMAIL PROTECTED]> writes:
> I think you can remove this one. I actually do have scripts to do the
> common archive operations, which I only wrote fairly recently. I
> don't think it's a good idea to allow developers to activate them
> directly.
Please provide a rationale. Do you thin
James Troup <[EMAIL PROTECTED]> writes:
> > (btw severity "important-ish" means severity normal to the BTS - see
> > #24255)
>
> Duh; I'm well aware of that, I used it for that reason. Please stop
> being so damn condescending and also stop telling me what to do; I'll
> do what I want, not what
Roman Hodek <[EMAIL PROTECTED]> writes:
> Not even that... you also need some kind of source dependencies,
> except you want to install the whole of Debian on the build machine,
> plus a bit more (e.g. Tcl/Tk sources etc.)
I was assuming all of the Debian dev packages would be installed on these
James Troup <[EMAIL PROTECTED]> writes:
> Martin Mitchell <[EMAIL PROTECTED]> writes:
>
> > Yes, but not all of them, and not to the extent that you could call
> > it full unattended (NB not unsupervised) autocompiling.
>
> Rubbish.
Would you like to elabo
James Troup <[EMAIL PROTECTED]> writes:
> I think your ad hominems are unjustified and unnecessary, Martin.
Hehe, maybe give credit to manoj for this line. :)
> > You say we now have people helping Guy, who are they?
>
> Richard Braakman and myself.
Fine, well now that Incoming is clear, how a
Rob Browning <[EMAIL PROTECTED]> writes:
> The Gecko <[EMAIL PROTECTED]> writes:
>
> > Are the even partially possible or are these desirable goals not to be
> > attempted?
>
> My impression from recent conversations was that we were leaning in
> the direction of not having our goals coupled to
James Troup <[EMAIL PROTECTED]> writes:
> Shaleh <[EMAIL PROTECTED]> writes:
>
> > Not to speak for him but, I take this to mean auto creation of debs
> > from a central repository. An idea that has been kicked around for
> > a while. With new machines coming RSN we should be able to have one
>
James Troup <[EMAIL PROTECTED]> writes:
> > * Developer controlled automatic archive maintenance (eg removal of
> > packages automatically after GPG signed email with list of
> > packages to delete)
>
> I think this idea, as presented here, is very bad. Even with sanity
> checks and more tho
Yann Dirson <[EMAIL PROTECTED]> writes:
> Maybe some will think it's not yet time to discuss this, but I think
> we need a central repository for ideas of what the release goals for
> slink will be.
>
> The following list is only built from what I remember to have read at
> some point, so it will
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Can we possibly change dpkg-buildpackage to check for gpg, and
> then pgp, and not to fall flat on it's face when something is not
> found? Like use gpg by preference, or use pgp if available, or gently
> wanr the use that pgp does not exist
Raul Miller <[EMAIL PROTECTED]> writes:
> Martin Mitchell <[EMAIL PROTECTED]> wrote last week:
> > > What's protocol on closing bugs in someone else's package when it's
> > > clear that the bugs were actually fixed (in a maintainer release or by
Zed Pobre <[EMAIL PROTECTED]> writes:
> What's protocol on closing bugs in someone else's package when it's
> clear that the bugs were actually fixed (in a maintainer release or by
> the circumstances around the bug changing) some time ago but stayed open
> in the tracking system? So far my defau
Raul Miller <[EMAIL PROTECTED]> writes:
> > I'd like to suggest that the issue be raised on debian-policy at some
> > stage, preferably before the package was released.
>
> Indeed, debian-policy should get all bug reports filed against policy.
> I'd prefer that the list be registered as the main
Raul Miller <[EMAIL PROTECTED]> writes:
> >> This is the second draft of this document <<
>
> I think I've waited long enough for comments on the points where I asked
> questions. Which is to say: I'm winging it.
>
> If there are no substantial comments on this for a while, it'll
> probably be t
"Oliver Elphick" writes:
> To get the meaning you want, the text should say:
>
>"Packages should specify only the first three digits ..."
> or just
>"Packages should specify the first three digits ..."
Correct, however I think that was the intention of the wording, and it
should be clar
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Santiago> The changelog says:
> Santiago> If only the patch-level digit is incremented, no changes in
> Santiago> policy have been made, except bug fixes and
> Santiago> clarifications. Packages only have to specify the first
> Santiago> three digits
[EMAIL PROTECTED] (Adam P. Harris) writes:
> File renaming is up to the package maintainer. Give us our freedom to
> make out operating environment better than anyone's!
I'm not trying to remove freedom. However consider it from the perspective
of an upstream author: they may not wish to see the
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Martin> I don't call changing filenames in original documentation
> Martin> easily maintainable.
>
> I find this hardly onerous at all. I have a rules file. It was
> set up when I first set up the package. This aspect has never needed
> to be
Rob Browning <[EMAIL PROTECTED]> writes:
> Why? I've had to rename or symlink upstream files in the past to
> comply with policy. It takes about one line in debian/rules. How's
> that hard to maintain?
If you symlink them I'd say that was good. If you rename them, you should
also rename any re
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Ny proposal is to stop micromanagement and leave some things
> for the maintainer to decide. As long as a changelog.gz entity
> exists, the maintainer should be competent enough to determine what
> goes in there. They know their package best.
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Oh, I think this symlink idea should definitely be optional;
> and only if the maintainer wants it so.
How can we keep the upstream docs consistent with themselves, while keeping
the whole Debian system consistent? The changelog.gz symlink sho
"Christian Hudon" <[EMAIL PROTECTED]> writes:
> Right now, I cat the files together in the right order and install the
> result as /usr/doc/lynx/changelog.gz It's consistent with other Debian
> packages, and it allows the whole thing to be extracted automaitcally by a
> script.
Consistent with ot
[EMAIL PROTECTED] writes:
> It is already Debian's policy that the maintainer modify the documents to be
> up to date with the debian package.
I could not locate this in section 5 of the policy manual, can you tell me
where to find it please?
Even if this is the case, I would still suggest the p
Dale Scheetz <[EMAIL PROTECTED]> writes:
> > Would adding a
> > ln -s ChangeLog.gz /usr/doc/xyzzy/changelog.gz
> > to your rules file as David Engel suggested be acceptable? It complies
> > with the letter of policy and doesn't force you to change the upstream
> > documentation.
>
> While thi
Santiago Vila <[EMAIL PROTECTED]> writes:
> Well, now that the Debian ports generate a lot of postings in
> debian-devel-changes, I think it is time to split that list by
> architecture.
I think a more complete approach is needed for this issue. Other things
which should be considered:
- Changin
57 matches
Mail list logo
