On 01-Aug-99, 16:31 (CDT), Nicolás Lichtmaier <[EMAIL PROTECTED]> wrote:
> > 75%. http://kitenet.net/programs/debhelper/stats/
> > (A little out of date, hasn't been updated in a month, but it will soon..)
>
> It should be higher... the more packages uses debstd/debhelper, the less
> lines of co
On 02-Aug-99, 11:22 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
>
> Yes, I agree helper packages would help, but those who chose not to use a
> helper package should not be "punished" for that.
Please describe how they are being "punished". If I choose not to use
a tool (and there are many l
> I´d prefer a syntax in the style of /etc/exports, e.g.
>
> Build-Depends: package1, package2(CPU1), package3(!CPU1),
> package4(SYSTEM2-CPU2, SYSTEM3-*), package5 | package6(CPU1),
> package7(CPU1, >= 2.0), package7(!CPU1, >= 2.1)
>
> It looks a bit easier to read (and create) to me than th
> Are the -Conflicts headers really necessary? So far I have not been
> able to think of a use for them, and they complicate the task of the
> build daemons ("install everything needed to build this package")
> unnecessarily.
That's not really true. The parsing is nearly the same, and it's no
tro
> Can we use a format that is more inline with the rest of the depends
> stuff? Perhaps:
>
> pkg (>= 2.1 i386)
>
> With the 'i386' being whatever specification you want to dream up.
> (optional of course)
At least better to parse than "package7(CPU1, >= 2.0)", as the version
can't
I proposed:
>> 1. REQUIRE that /usr/doc is a symlink to the FHS directory /usr/share/doc.
Joseph Carter replied:
> Breaks dpkg. Propose it all you want, but it's not going to happen if you
> don't provide the patch for dpkg to follow symlinks. Either that or all
> packages must be upgraded and
On Tue, Aug 03, 1999 at 10:56:22AM +0200, [EMAIL PROTECTED] wrote:
> I proposed:
>
> >> 1. REQUIRE that /usr/doc is a symlink to the FHS directory /usr/share/doc.
>
> Joseph Carter replied:
>
> > Breaks dpkg. Propose it all you want, but it's not going to happen if you
> > don't provide the pat
Roman Hodek wrote:
> But it's something different here... It's really trivial to
> temporatily uninstall a package and reinstall it later.
What if you can only uninstall the package by deconfiguring another one
that you need? Take this situation:
foo-source has
Build-Depends: gnu1 | gnu2
Bui
Dear Joseph Carter,
I'm sorry to shout but please read what I write.
> All right dammit, here we go... built a package crap 1.0-1, here is the
> listing:
>...
> /usr/lib/crap/olddir
>...
> Do you believe us yet? What more proof do you possibly need?
I am happy to tell you that we agree comple
> What if you can only uninstall the package by deconfiguring another one
> that you need? Take this situation:
>
> foo-source has
> Build-Depends: gnu1 | gnu2
> Build-Conflicts: bar
>
> gnu1 has
> Depends: bar
>
> Currently bar and gnu1 are installed. Will your five lines o
On Tue, Aug 03, 1999 at 12:05:39PM +0200, [EMAIL PROTECTED] wrote:
> I am happy to tell you that we agree completely on the behaviour of dpkg on
> your example. But you are ignoring a very important aspect of my proposal:
> THIS ONLY HAPPENS FOR DIRECTORIES INTERNAL TO PACKAGES. It happens beca
On Tue, Aug 03, 1999 at 12:05:39PM +0200, [EMAIL PROTECTED] wrote:
> What other problems could there be with my proposal.
Well, the real reason is that you're trying to rearrange 110M that might
be located on a filesystem other than the destination filesystem. If
someone's doing careful space mana
On Tue, Aug 03, 1999 at 09:21:05PM +1000, Anthony Towns wrote:
> Possibly I'm just misunderstanding what you're suggesting should be done
> though. Can you give a sequence of commands that does whatever you're
> suggesting, and still has those three packages survive unscathed?
That's simple enough
On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> IMHO, packages that
> started using /usr/share/doc were premature in that usage
Your opinion is wrong.
Those packages follow current policy. Not using /usr/share/doc in a
standards-version >= 3.0.0 package is a policy violation.
On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> On Tue, Aug 03, 1999 at 09:21:05PM +1000, Anthony Towns wrote:
> > Possibly I'm just misunderstanding what you're suggesting should be done
> > though. Can you give a sequence of commands that does whatever you're
> > suggesting, and
On Tue, 27 Jul 1999, Joseph Carter wrote:
> [...]
> To do this I suggest we ammend policy first by replacing all existing
> instances of /var/spool/mail with /var/mail and then changing the second
> paragraph of section 5.6 which currently reads
>
>The mail spool is /var/spool/mail and the in
On Tue, Aug 03, 1999 at 03:14:56PM +0300, Antti-Juhani Kaijanaho wrote:
> On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> > IMHO, packages that
> > started using /usr/share/doc were premature in that usage
>
> Your opinion is wrong.
>
> Those packages follow current policy. Not
Michael Stone on my proposal (available from
http://www.ens-lyon.fr/~krisrose/ftp/Debian/usr-doc-proposal.txt>):
> Well, the real reason is that you're trying to rearrange 110M that might
> be located on a filesystem other than the destination filesystem. [...]
You are right. At the moment the s
> Anthony Towns writes:
> > * Create three packages:
> > test1 version 1.0 mimicing your average /usr/doc-using package
> > test1 version 2.0 mimicing your average /usr/share/doc-using package
> > test3 version 1.0 mimicing base-files
> >
> > test1 1.0 has a file /my_usr/doc/test1/copy
On Tue, Aug 03, 1999 at 09:22:27AM -0400, Michael Stone wrote:
> Sure it's legal, but was it a good idea?
You could ask the same question from a different perspective: was it a
good idea to change policy to use /usr/share/doc before the transition
was hashed out? And is it a good idea to leave it
On Tue, Aug 03, 1999 at 12:05:39PM +0200, [EMAIL PROTECTED] wrote:
> Dear Joseph Carter,
>
> I'm sorry to shout but please read what I write.
>
> > All right dammit, here we go... built a package crap 1.0-1, here is the
> > listing:
> >...
> > /usr/lib/crap/olddir
> >...
> > Do you believe us y
On Tue, Aug 03, 1999 at 02:39:37PM +0200, Santiago Vila wrote:
> >While the FHS mandates the mail spool be accessable as /var/mail, it is
> >important to retain compatibility with older packages and locally
> >compiled programs. Packages using the mail spool should use /var/mail
> >
Hi
Here is my idea for dealing with the /usr/share/doc problem. Have a
symlink in /usr/doc for each package which has moved to /usr/share/doc.
The symlinks could be created by the postinst of each package (imho not a
good idea), or dpkg could be modified to run scripts in
/etc/post-dpkg-install.d
On Tue, Aug 03, 1999 at 06:07:55PM +0300, Antti-Juhani Kaijanaho wrote:
> On Tue, Aug 03, 1999 at 09:22:27AM -0400, Michael Stone wrote:
> > Sure it's legal, but was it a good idea?
>
> You could ask the same question from a different perspective: was it a
> good idea to change policy to use /usr/
On Tue, Aug 03, 1999 at 12:11:21PM -0400, Michael Stone wrote:
> If people
> would have some patience to wait for a consensus, we could do this with
> less argument, IMHO.
It should be possible for a developer to trust the policy documents.
If they don't reflect the consensus, the policy document
On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> On Tue, Aug 03, 1999 at 09:21:05PM +1000, Anthony Towns wrote:
> > Possibly I'm just misunderstanding what you're suggesting should be done
> > though. Can you give a sequence of commands that does whatever you're
> > suggesting, and
On Tue, Aug 03, 1999 at 06:07:55PM +0300, Antti-Juhani Kaijanaho wrote:
> > Sure it's legal, but was it a good idea?
>
> You could ask the same question from a different perspective: was it a
> good idea to change policy to use /usr/share/doc before the transition
> was hashed out? And is it a go
On Tue, Aug 03, 1999 at 07:29:43PM +0300, Antti-Juhani Kaijanaho wrote:
> > If people
> > would have some patience to wait for a consensus, we could do this with
> > less argument, IMHO.
>
> It should be possible for a developer to trust the policy documents.
> If they don't reflect the consensus,
On Tue, Aug 03, 1999 at 09:35:52AM -0700, Joseph Carter wrote:
> On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> > That's simple enough. This all only works if there is no /usr/share/doc
> > and you can move /usr/doc in an atomic operation.
>
> Your assessment is flawed---it assum
On Tue, Aug 03, 1999 at 05:00:21PM +0100, [EMAIL PROTECTED] wrote:
> Here is my idea for dealing with the /usr/share/doc problem. Have a
> symlink in /usr/doc for each package which has moved to /usr/share/doc.
We wanted to do this---a few people don't like symlinks and effectively
killed off the
On Tue, Aug 03, 1999 at 09:45:25AM -0700, Joseph Carter wrote:
> On Tue, Aug 03, 1999 at 06:07:55PM +0300, Antti-Juhani Kaijanaho wrote:
> > > Sure it's legal, but was it a good idea?
> >
> > You could ask the same question from a different perspective: was it a
> > good idea to change policy to u
On Tue, Aug 03, 1999 at 12:56:41PM -0400, Michael Stone wrote:
> > Ignore the problem and it'll go away? feh.
>
> Is it the end of the world if there's a symlink from /usr/doc to
> /usr/share/doc? Will the sky fall, or will there be other similarly
> important reasons for dealing with it immediat
[EMAIL PROTECTED] (Santiago Vila) wrote on 29.07.99 in <[EMAIL PROTECTED]>:
> * Every package install files in /usr/doc/.
Well, every package *should* do that.
MfG Kai
[EMAIL PROTECTED] (Steve Greenland) wrote on 17.07.99 in <[EMAIL PROTECTED]>:
> BTW, both this proposal (#40766) and the general clean-up proposal
> (#40767) are currently stalled with only one official seconder (Joey
> Hess). I'd guess that Hamish generally approves...but unless I get at
> least
On Tue, Aug 03, 1999 at 09:53:24AM -0700, Joseph Carter wrote:
> Those people now wanting to undo the change had
> plenty of opportunity to cause the change to never happen in the first
> place.
Are you saying I should be actively violating Policy?
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTE
[EMAIL PROTECTED] (Julian Gilbey) wrote on 18.07.99 in <[EMAIL PROTECTED]>:
> Seconded.
Seconded.
MfG Kai
[EMAIL PROTECTED] (Richard Braakman) wrote on 02.08.99 in <[EMAIL PROTECTED]>:
> Is there any case where one would want a Build-Conflicts? Allowing
> them will complicate all the code that deals with build dependencies,
> whether they are used or not.
The only one I can think of is configure pi
On Tue, Aug 03, 1999 at 08:56:10PM +0300, Antti-Juhani Kaijanaho wrote:
> Are you saying I should be actively violating Policy?
Oops, I think I misread Joseph. Sorry.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
"... memory leaks are quite acceptable in ma
On Tue, Aug 03, 1999 at 09:53:24AM -0700, Joseph Carter wrote:
> We had a consensus. Those people now wanting to undo the change had
> plenty of opportunity to cause the change to never happen in the first
> place.
ITYM "Those people now wanting to have a decent transition method
had plenty of op
On 3 Aug 1999, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Richard Braakman) wrote on 02.08.99 in <[EMAIL
> PROTECTED]>:
>
> > Is there any case where one would want a Build-Conflicts? Allowing
> > them will complicate all the code that deals with build dependencies,
> > whether they are used
On Tue, Aug 03, 1999 at 08:56:10PM +0300, Antti-Juhani Kaijanaho wrote:
> > Those people now wanting to undo the change had
> > plenty of opportunity to cause the change to never happen in the first
> > place.
>
> Are you saying I should be actively violating Policy?
I'm saying our effort should
On Tue, Aug 03, 1999 at 10:14:17PM +1000, Anthony Towns wrote:
> On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> > On Tue, Aug 03, 1999 at 09:21:05PM +1000, Anthony Towns wrote:
> > > Possibly I'm just misunderstanding what you're suggesting should be done
> > > though. Can you giv
On Wed, Aug 04, 1999 at 12:46:34AM +1000, Anthony Towns wrote:
> Then please provide a test3 .deb that *does* work. Simply getting rid of
> all the /my_usr/doc references in test3 is *not* enough.
>
> * install test3_2.0_all.deb
> * note that /my_usr contains /my_usr/share but not /my_usr/doc
> *
On Tue, Aug 03, 1999 at 05:44:40PM -0400, Michael Stone wrote:
> On Wed, Aug 04, 1999 at 12:46:34AM +1000, Anthony Towns wrote:
> > Then please provide a test3 .deb that *does* work. Simply getting rid of
> > all the /my_usr/doc references in test3 is *not* enough.
> > * install test3_2.0_all.deb
>
On Tue, Aug 03, 1999 at 05:32:33PM -0400, Michael Stone wrote:
> > > > Possibly I'm just misunderstanding what you're suggesting should be done
> > > > though. Can you give a sequence of commands that does whatever you're
> > > > suggesting, and still has those three packages survive unscathed?
> >
On the /usr/share/doc vs. /usr/doc issue
Given that:
- we're going in circles at present
- dpkg is unlikely to be fixed in the near future, and relying on the
user having a working dpkg is a dangerous assumption
- most packages use either debhelper or debstd
why don't we follow the Per
On Tue, Aug 03, 1999 at 08:32:57AM -0700, Joseph Carter wrote:
> > I second this proposal, but please change the word "dependency"
> > by "Pre-Dependency" (otherwise I would formally object ;-).
> > Rationale: base-files (>=whatever) must be unpacked and *configured*
> > before *any* package using
Joeyh has *NOT* modified debhelper. This is a conscious decision, not slacking.
He states that he will change it when policy has decided what the right thing
is. Until then debhelper stands as is.
Sean 'Shaleh' Perry wrote:
> Joeyh has *NOT* modified debhelper. This is a conscious decision, not
> slacking.
> He states that he will change it when policy has decided what the right thing
> is. Until then debhelper stands as is.
Sean knows exactly where I stand on this issue. I just want to a
49 matches
Mail list logo
