[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bricolage-devel
Subject:    Re: [Bricolage-Devel] New README.Debian
From:       Gerfried Fuchs <alfie () users ! sourceforge ! net>
Date:       2003-05-22 8:53:17
[Download RAW message or body]

* Chris Jantzen <chris-bric@maybe.net> [2003-05-21 11:21]:
> On Wed, May 21, 2003 at 11:07:05AM -0700, David Wheeler wrote:
>> On Tuesday, May 20, 2003, at 01:13  AM, Gary wrote:
>> >No. But it's a moving target, I think. Someone is working on a Debian
>> >package, that may be available now, at least in a beta form. That 
>> >should be in the readme, if it becomes available.

 That someone is me, and I'm not that far, sorry.

>> >What is there in the README.Debian should be updated. (Also, someone 
>> >objected to it being called README.Debian because Debian uses that 
>> >file name for something else.)

 Yep. README.Debian is a file in which the package maintainer puts
his/her informations about the debian package itself.  But IMHO that
doesn't mean that you can't use that file in your sources to host
informations about how to get it running on Debian -- because such
informations won't be installed into the binary package anyway and thus
there simply is no name conflict here.

>> >If nothing else, the readme refers to 2.2 as being current, whereas 
>> >the current stable debian is 3.0. What I wrote isn't really 
>> >appropriate, I realized. It was too specific to my own needs and 
>> >quirks.

 I am willing to send an update to the file, just currently am quite
busy with the organisation of a big upcoming event here in austria
(<http://www.linuxwochen.at/> if someone is interested and able to read
german language informations :)

> Yeah, I'm not sure. My understanding is that README.Debian is reserved
> for the package maintainer to put notes in regarding changes made or how
> to set up the Debian package according to how it was packaged.

 Like I said above, that is true -- but it still doesn't conflict
because the intention of the file in the bricolage tree is to put
informations in how to get it running on a Debian system (like a INSTALL
file) and such files must not be put into the binary packages anyway. So
no problem with that file at all.

> I also understand that it's part of the .diff applied to the original
> source when the package is built. I don't know what happens when
> upstream is willing to include the ./debian/ control directory as
> well. I'll ask on -mentors.

 It is usually no good idea to have the files in the debian directory in
the upstream source, especially when the person responsible for it
doesn't have cvs write access. Usually the package maintainers strip
such a directory completely and apply their own, which means additional
work for them, which can be avoided.

 So long,
Alfie
-- 
<Alfie> Von sid wirds nie ein netinst geben.
<hygl> Alfie: darf ich dich damit zitieren, wenn sid stable ist?
                    -- #debian.de

[Attachment #3 (application/pgp-signature)]
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

[prev in list] [next in list] [prev in thread] [next in thread]