reopen 177523
reassign 177523 developers-reference
thanks
Regarding bug 177523, I agree there may be some merit to this
recommendation but I am not totally clear. what are the situations
where trailing whitespace is problematic?
Regarding trailing whitespace in syslog, isn't that an issue which
Dan Jacobson <[EMAIL PROTECTED]> writes:
> Dear developers reference, I was told these might be useful.
> Bug#185364 Bug#177523
Regarding bug 185364, I already do recommend that the "Homepage" be
added to the package description.
--
.Adam Di [EMAIL PROTECTED]http://www.debian.org/>
I second it as well. I think it provides a nice core to what is added
as "description best practices" in developers-reference. I don't
believe there are any contradictions between the two.
--
...Adam Di Carlo...<[EMAIL PROTECTED]>...http://www.onshored.com/>
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Sun, Jan 26, 2003 at 12:55:05PM -0500, Russell Nelson wrote:
> > Hi. I'm the vice-president of the Open Source Initiative, and I'm
> > writing to you today in that stead.
>
> > We want to explore convergence between the Open Source Definition, and
Jochen Voss <[EMAIL PROTECTED]> writes:
> > and (c)
> > describe what goes in /usr/share/doc/foo-doc (just changelog and
> > README.Debian pointing to /usr/share/doc/foo?),
> That would be fine with me. But do we really need to
> regulate this?
I'm not saying "regulate", just make it clear that
Ron <[EMAIL PROTECTED]> writes:
> But even the OP agreed that not every piece of software is necessarily
> portable in which case I also agree it's up to someone who wants it on
> the port to do the porting -- the Debian maintainer is not obliged to
> port i386 assembly to some other platform just
Ron <[EMAIL PROTECTED]> writes:
> If -policy wants to run a flame war
Hey, who ever wants a flame war?
> on this topic now, knock yourselves out, but can we please leave the
> bts report off the cc, and probably also the OP (who I can't speak
> for) and myself (who I just have ;).
>
> As I've s
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Is a developer merely a glorified packager, who mechanically
> packages software, and shuffles off problems with the package
> blindly upstream? I hope not, and I have long rejected this narrow
> view of what a developer is.
Ahem, that is a
"Steven G. Johnson" <[EMAIL PROTECTED]> writes:
> On 18 Jan 2003, Adam DiCarlo wrote:
> > But I do think this goes too far. There might be good reasons why the
> > upstream maintainers or debian maintainers are unable to maintain a
> > ported package -- nota
[I'll preface by saying I should have modulated my first post a little
bit more than I did -- you see a more balanced approach in my second
one.]
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> > I really don't understand this. The maintainers of the software the
> > the upstream folks who provi
"Steven G. Johnson" <[EMAIL PROTECTED]> writes:
> 2. Don't set architecture to a value other than ``all'' or ``any''
> unless the upstream package is intrinsically unportable
> (e.g. a program to disable a Pentium CPU ID). If the package
> is theoretically portable, even i
"Steven G. Johnson" <[EMAIL PROTECTED]> writes:
> He (Ron Lee <[EMAIL PROTECTED]>) responded:
> > I can quite sympathise with what you want, but I'm not going to
> > make this package arch-any just so it can break on every arch
> > except i386 (and hence keep it out of testing for everyone).
> > T
If you could (a) convert this into a proper policy change proposal,
(b) fix the /usr/share/foo where you meant /usr/share/doc/foo, and (c)
describe what goes in /usr/share/doc/foo-doc (just changelog and
README.Debian pointing to /usr/share/doc/foo?), I would be willing to
secondary the proposal.
I'm willing to second the proposal as is, with the "must" directive.
I do think there should be an impact analysis done, a quick one: how
many packages in main do interactive prompting?
I'm personally not afraid of making 30% of packages suddenly buggy if
that's what it takes to make Debian bett
Bill Allombert <[EMAIL PROTECTED]> writes:
> The first step is to upload a new menu package that support menu in both
> /usr/lib/menu and /usr/share/menu. The package is ready and will be uploaded
> soon.
This seems like the wrong way to do it. Isn't the right way to have
the maintainer script m
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> > This does feel like a debian-devel or debian-project issue rather than
> > a policy issue, too...?
>
> It is relevant to the discusison though.. do we want to bloat the
> Packages file with usptream author & homepage information as well?
Actually
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Previously Adam DiCarlo wrote:
> > Comments desired.
>
> Perhaps it makes sense to think about all fields people would possible
> want. The rpm format for example has a license field. Is that something
> that people would
This discussion has migrated a bit.
I think it *would* be good to have more structure in debian/copyright
files (e.g., /usr/share/doc/pkg/copyright). What here could be
structured? Well:
- where source came from
- what kind of license is it (we'd define the set of common licenses,
e.g., M
My only problem with using the download location URL is not a
technical one, but rather than download locations are not software
home pages, and the one can't in all cases be derived from the other.
--
...Adam Di Carlo..<[EMAIL PROTECTED]>...http://www.onshored.com/>
The consensus we arrived at on debian-doc list (with the exception of
Colin Walters) was that XML/SGML source is in fact source and
shouldn't be there bloating binary pkgs. Just FYI. Not that I'm
proposing this as a policy item, although it might become DDP policy,
who knows.
--
...Adam Di Car
Josip Rodin <[EMAIL PROTECTED]> writes:
> On Tue, Dec 10, 2002 at 09:03:54AM -0600, Adam DiCarlo wrote:
> > As for the extra work, it doesn't matter.
>
> It's not nice to screw around with other people's time like that.
I was under the guess that given t
Josip Rodin <[EMAIL PROTECTED]> writes:
> On Mon, Dec 09, 2002 at 01:17:28PM -0600, Adam DiCarlo wrote:
> > > The point was validly raised in a previous thread that using these means
> > > changing packages twice in the event that dpkg is eventually changed.
&
[EMAIL PROTECTED] (Denis Barbier) writes:
> For translators having a development URL is also useful, because they can
> then send up to date translations; it was said that it is then available
> from package homepage, but some packages have no homepage and have a
> public CVS repository.
> It woul
Britton <[EMAIL PROTECTED]> writes:
> I don't like this. The pages listed will end up being wrong half
> the time
Then file a minor bug. Half the time is a bit overstating, no?
> and google can find homepages very well and everybody knows
> it, so what is the point in adding this?
Can you say
Colin Watson <[EMAIL PROTECTED]> writes:
> On Sun, Dec 08, 2002 at 09:43:00PM -0600, Adam DiCarlo wrote:
> > Colin Watson <[EMAIL PROTECTED]> writes:
> > > We could just use the existing support for user-defined fields for a
> > > while though.
> >
James Troup <[EMAIL PROTECTED]> writes:
> Adam DiCarlo <[EMAIL PROTECTED]> writes:
>
> > Ok, here's my revision from suggestions. Added a screenshot link,
> > what the hell, it's all optional anyhow, and it's kinda a cute idea.
>
> Err, do we
Ok, here's my revision from suggestions. Added a screenshot link,
what the hell, it's all optional anyhow, and it's kinda a cute idea.
We recommend that you add the URL for the package's homepage to
the package description in 'debian/control', and a link to a
screenshot, if one is
Colin Walters <[EMAIL PROTECTED]> writes:
>- It would in theory let software like doc-base dynamically generate
> the documentation formats the user desires after installation.
The more I think about this idea of building on install, though, the
more I think it's completely insane. At least
"Christopher W. Curtis" <[EMAIL PROTECTED]> writes:
> I really don't see much reason for an upstream maintainer,
Yes, there's been a lot of good arguments for not bothering with the
maintainer name. You can get that from the pkg home page tho...
> specifically, but a pointer to a mailing list o
Colin Watson <[EMAIL PROTECTED]> writes:
> We could just use the existing support for user-defined fields for a
> while though.
Oh ! Where can I read about these? They aren't mentioned in
deb-control(5) or /usr/share/doc/dpkg nor /usr/share/doc/dpkg-dev ...
--
...Adam Di Carlo..<[EMAIL PROTEC
I'd like to make a "best practices" note in the developers-reference
about how to indicate the upstream author, author's email, and home
page in the package description. I think this is would be a nice
thing.
Ideally debian/control's known fields would be extended, e.g.,
Upstream-Maintainer:
I have a question for further discussion, which I'm unsure about. May
or may not be a policy issue.
Is it a good practice for SGML or XML documentation to ship with
source?
Pros:
- providing source lets contributors make patches more easily
Cons:
- wastes disk space
- why bother, just get
Colin Watson <[EMAIL PROTECTED]> writes:
> I appreciate the work!
Well, more to come. Let me know if you have any suggestions either
for the maint fixing or the redesigned version.
--
...Adam Di Carlo..<[EMAIL PROTECTED]>...http://www.onshored.com/>
As the doc-base maintainer, some comments on the progress of this bug.
On Sun, Nov 17, 2002 at 02:01:29AM +, Colin Watson wrote:
> It would be cool if somebody could figure out how to fix #114692
> first. :( Packages with many distinct pieces of additional
> documentation can't practicably u
34 matches
Mail list logo
