Steve Greenland wrote:
> Maybe, maybe not. Debhelper is great if the package fits into the GNU
> mold.
Eh? I've had no problems using debhelper on packages that, say, trace their
ancestry back to ms-dos (abuse, megahal). These certianly don't fit into the
GNU mold, whatever that may be.
> On othe
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
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 Sat, 31 Jul 1999, Joey Hess wrote:
> Santiago Vila wrote:
> > I would like you to elaborate on that. I think it makes sense that the
> > more difficult the migration process is, the longer it will take, and your
> > proposal complicate things in a considerable degree.
>
> That's simply not so.
> > I'd say that 95% of packages use debhelper or debmake.
> 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 code that need maintenainc
Nicolás Lichtmaier wrote:
> I'd say that 95% of packages use debhelper or debmake.
75%. http://kitenet.net/programs/debhelper/stats/
(A little out of date, hasn't been updated in a month, but it will soon..)
--
see shy jo
Santiago Vila wrote:
> I would like you to elaborate on that. I think it makes sense that the
> more difficult the migration process is, the longer it will take, and your
> proposal complicate things in a considerable degree.
That's simply not so. Whatever we eventually decide on, 60% of the packa
Hi,
>>"Peter" == Peter S Galbraith <[EMAIL PROTECTED]> writes:
>> ps. How stupid do you think I am?
Peter> Why would you think that I think you are stupid?
You indicated that in one mail message I argued that all
packages can have the postinst changed in a jiffy, and, in another,
on
Hi,
>>"Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes:
Julian> Maybe I can suggest an alternative which will
Julian> - not require packages to add anything to their maintainer scripts
Julian> - not break the majority of packages, and
Julian> - not create a forest of symlinks (which mig
Manoj Srivastava wrote:
> Hi,
> >>"Peter" == Peter S Galbraith <[EMAIL PROTECTED]> writes:
>
> Peter> Manoj, you can't argue that all developers can quickly add a
> Peter> postinst script, and argue a few posts earlier that it will take
> Peter> 18 months for all packages to get done. Can yo
Roland Rosenfeld wrote:
> On Tue, 20 Jul 1999, Peter S Galbraith wrote:
>
> > Manoj, you can't argue that all developers can quickly add a
> > postinst script, and argue a few posts earlier that it will take 18
> > months for all packages to get done. Can you?
>
> He can. Please have a look at
On Tue, 20 Jul 1999, Peter S Galbraith wrote:
> Manoj, you can't argue that all developers can quickly add a
> postinst script, and argue a few posts earlier that it will take 18
> months for all packages to get done. Can you?
He can. Please have a look at our BTS. There are many bug reports
pers
Maybe I can suggest an alternative which will
- not require packages to add anything to their maintainer scripts
- not break the majority of packages, and
- not create a forest of symlinks (which might be problematic, as has
been pointed out)
The dpkg-buildpackage program (and maybe autobuil
> Manoj, you can't argue that all developers can quickly add a
> postinst script, and argue a few posts earlier that it will take
> 18 months for all packages to get done. Can you? If it's so
> quick to do, why can't it be done quickly? I know I'll probably
> do my 7 packages in one sitting.
>
Hi,
>>"Peter" == Peter S Galbraith <[EMAIL PROTECTED]> writes:
Peter> Manoj, you can't argue that all developers can quickly add a
Peter> postinst script, and argue a few posts earlier that it will take
Peter> 18 months for all packages to get done. Can you? If it's so
Peter> quick to do, wh
Manoj Srivastava wrote:
> * The transition may take a long time, going by previous
> transitions, and not all packages are upgraded anywhere near
> simultaneously.
>
> I think that expecting _*all*_ packages to have moved before we
> release potato
Hi,
Being too much work is not the only point, the point is that this work
would be quite useless.
There will be users who will like the symlinks, but there will be also
users who will dislike them (have we thought of them too?).
If a user likes the symlinks, he/she may create by himself/herself
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> I would like you to elaborate on that.
I doubt that planning for a controlled transition is going to
slow the transition down. Not releasing potato cause we are still not
done and had not planned on the transition
Hi,
>>"Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:
Branden> On Fri, Jul 16, 1999 at 02:10:02PM -0700, Ben Gertzfield wrote:
>> If I remember, dpkg does not like replacing a directory with a
>> symlink. This may or may not still be the case.
Branden> Or vice versa.
Indeed
Ups.. I haven't read the constitution yet... =)
May I second this proposal or I need a special hat? (I hope not a red one).
> > Create the symlink in post inst. dpkg need not be involved.
> Ah, but then this is not a simple one-line addition, as you said.
> For most of my packages, I have to change just one line in debian/rules
> to be FHS-compliant. With your proposal, the amount of work is not doubled
> by may
On Fri, Jul 16, 1999 at 02:10:02PM -0700, Ben Gertzfield wrote:
> If I remember, dpkg does not like replacing a directory with a
> symlink. This may or may not still be the case.
Or vice versa.
I can attest to this. This little landmine blew up in my face about 100
times while I was reorganizing
On Mon, 19 Jul 1999, Santiago Vila wrote:
> For most of my packages, I have to change just one line in
> debian/rules to be FHS-compliant. With your proposal, the amount of
> work is not doubled by maybe multiplied by three or four.
How many hundreds of packages do you maintain? I think this disc
On 19 Jul 1999, Manoj Srivastava wrote:
> Santiago> I will not insist *all* packages must move to
> Santiago> /usr/share/doc, but those who do not are buggy anyway (with
> Santiago> or without this proposal).
>
> Santiago> I think it is *this* proposal what will slow down the
> Santiago> tra
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
>> Create the symlink in post inst. dpkg need not be involved.
Santiago> Ah, but then this is not a simple one-line addition, as you said.
Oooh,m yes. One shall have the onerous burden of adding a well
published stanza to p
On 16 Jul 1999, Manoj Srivastava wrote:
> Hi,
> >>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
>
> Santiago> This is not as simple.
>
> Santiago> Symlinking /usr/doc/ to /usr/share/doc/
> Santiago> directly is not supported by dpkg, so additional and ugly
> Santiago> tweaks would
Roland Rosenfeld wrote:
> If there really is a technical problem with this link as mentioned by
> Santiago (I didn't check this myself), we can handle this symlink in
> postinst:
I second this proposal (I mean the whole symlink proposal, not just this
addition).
--
Stefan Gybas
On Fri, Jul 16, 1999 at 02:20:17PM -0700, Joey Hess wrote:
> Ben Gertzfield wrote:
> > If I remember, dpkg does not like replacing a directory with a
> > symlink. This may or may not still be the case.
>
> Ugh, you're right:
[...]
> I still think this is a good proposal -- if we could only fix d
On Fri, Jul 16, 1999 at 01:11:36PM -0700, William Ono wrote:
> > Symlinking /usr/doc/ to /usr/share/doc/ directly
> > is not supported by dpkg, so additional and ugly tweaks would be required
> > in maintainer scripts.
>
> I believe the problem Santiago brings up is that dpkg will become confused
> William> I believe the problem Santiago brings up is that dpkg will
> William> become confused by files appearing in both /usr/doc/package
> William> and /usr/share/doc/package, through the symlink.
On 16 Jul 1999, Manoj Srivastava wrote:
> Really? Can you provide details, please?
So
On Fri, 16 Jul 1999, Manoj Srivastava wrote:
> I propose that there be a syymlink from /usr/doc/ ->
> /usr/share/doc/, managed by the p[ackage itself. This is how
> it works:
>
> a) Policy 3.X mandates that packages that move the docs to
>/usr/share/doc must provide a compatibility
Ben Gertzfield wrote:
> If I remember, dpkg does not like replacing a directory with a
> symlink. This may or may not still be the case.
Ugh, you're right:
[EMAIL PROTECTED]:/tmp/scratch>dpkg --contents foo.deb
drwxrwxr-x joey/joey 0 1999-07-16 14:11 ./
drwxr-xr-x joey/joey 0
Hi,
>>"William" == William Ono <[EMAIL PROTECTED]> writes:
William> I believe the problem Santiago brings up is that dpkg will
William> become confused by files appearing in both /usr/doc/package
William> and /usr/share/doc/package, through the symlink.
Really? Can you provide details,
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Santiago> Symlinking /usr/doc/ to
Santiago> /usr/share/doc/ directly is not supported by
Santiago> dpkg, so additional and ugly tweaks would be required in
Santiago> maintainer scripts.
Joey> Could you be a little more clea
Santiago Vila wrote:
> Symlinking /usr/doc/ to /usr/share/doc/ directly
> is not supported by dpkg, so additional and ugly tweaks would be required
> in maintainer scripts.
Could you be a little more clear? Symlinking of /usr/doc/ to
/usr/doc/ clearly works and doesn't bother dpkg at all. Many
pac
I second this proposal.
I have reservations. I hope we have at least one release with a complete
forest of symlinks, and do not remove them until the release after. I'm not
too happy with even doing that, as backwards compatability problems still
exist, but I think it's a decent compromise to requ
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> This is not as simple.
Santiago> Symlinking /usr/doc/ to /usr/share/doc/
Santiago> directly is not supported by dpkg, so additional and ugly
Santiago> tweaks would be required in maintainer scripts.
Create the sy
> On 16 Jul 1999, Manoj Srivastava wrote:
> > I propose that there be a syymlink from /usr/doc/ ->
> > /usr/share/doc/, managed by the p[ackage itself.
On Fri, 16 Jul 1999, Santiago Vila wrote:
> Symlinking /usr/doc/ to /usr/share/doc/ directly
> is not supported by dpkg, so additional an
On 16 Jul 1999, Manoj Srivastava wrote:
> I propose that there be a syymlink from /usr/doc/ ->
> /usr/share/doc/, managed by the p[ackage itself.
>
> [...]
>
> I think the handicap of having to remove a line from the rules
> file (and no action for people who use helper packages)
Hi,
Now that policy 3.0.1 is out, we neede to have a means of
tackling the /usr/doc ==> /usr/share/doc transition.
(A)The transition may take a long time, going by previous
transitions, and not all packages are upgraded anywhere
near simultaneously.
Manoj Srivastava wrote:
> Hi,
> >>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
>
> Richard> The best thing to do is probably to make sure that /usr/doc/ and
> Richard> /usr/share/doc end up on the same filesystem, but in separate
> Richard> directories.
>
> Umm, how do we
> >>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
>
> Richard> The best thing to do is probably to make sure that /usr/doc/ and
> Richard> /usr/share/doc end up on the same filesystem, but in separate
> Richard> directories.
>
> Umm, how do we do that? We have really no con
On Thu, Jul 08, 1999 at 10:46:30AM -0500, Manoj Srivastava wrote:
>
> Richard> The best thing to do is probably to make sure that /usr/doc/ and
> Richard> /usr/share/doc end up on the same filesystem, but in separate
> Richard> directories.
>
> Umm, how do we do that? We have really no
Hi,
>>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
Richard> The best thing to do is probably to make sure that /usr/doc/ and
Richard> /usr/share/doc end up on the same filesystem, but in separate
Richard> directories.
Umm, how do we do that? We have really no control over
> My idea (please note, this is only a first idea and there may be some
> difficulties with which should be fixed) is, that the new (FHS aware)
> debhelper could add something in postinst, which creates a symlink
> /usr/doc/ pointing to /usr/share/doc/ if (and only
> if) there is no special "flag"
Ron wrote:
> What I had hoped I could do in this case would be simply to remount
> the /usr/doc partition as /usr/share/doc and then symlink /usr/doc
> to it.. however it was previously indicated that this might cause
> problems with dpkg..
The best thing to do is probably to make sure that /usr/
Le Wed, Jul 07, 1999 at 05:38:04PM +0200, Santiago Vila écrivait:
> We could have some sort of FHS-threshold for the release:
>
> "We will not release until 90% of all priority >= standard packages are
> converted to use /usr/share/doc" or else "we will not release until 80% of
> the 300 most popu
> It would help because /usr/doc could become almost empty *for a typical
> system*. (Not if you install the 2500+ packages, of course).
..actually this is almost exactly the *problem* that this change is
going to cause one of my debian boxes.
I have a box that uses several smallish drives.. so
Santiago Vila wrote:
> For people not using helper tools (there are many of them), this means
> *double* work for every package, because you have first to provide
> symlinks and then you have to remove them.
It can be pretty easy to do. Make an update-doc-symlinks script, that takes
a single (add/
On Wed, 07 Jul 1999, Santiago Vila wrote:
> However, if we convert 90%, 80% or just 20% of them (if the most
> popular ones are included in that 20%), then it would not be such a
> disaster, IMHO.
IMHO only 0% or 100% aren't a disaster. Everything else is annoying,
at least for me as a user.
But
On Wed, 7 Jul 1999, Roland Rosenfeld wrote:
> On Wed, 07 Jul 1999, Santiago Vila wrote:
>
> > > With this we have the following four stages:
>
> > For people not using helper tools (there are many of them), this
> > means *double* work for every package, because you have first to
> > provide sym
On Wed, 07 Jul 1999, Santiago Vila wrote:
> > With this we have the following four stages:
> For people not using helper tools (there are many of them), this
> means *double* work for every package, because you have first to
> provide symlinks and then you have to remove them.
>
> I do not think
On Wed, 7 Jul 1999, Roland Rosenfeld wrote:
> With this we have the following four stages:
>
> [snipped]
For people not using helper tools (there are many of them), this means
*double* work for every package, because you have first to provide
symlinks and then you have to remove them.
I do not
On Tue, 06 Jul 1999, Steve Greenland wrote:
> > I would prefer a way using postinst or dpkg to provide the
> > symlinks to be able to remove them at some point in the future
> > without uploading all packages (with the symlink removed) again.
> > But at the moment I don't fully know how to do thi
On 05-Jul-99, 15:23 (CDT), Roland Rosenfeld <[EMAIL PROTECTED]> wrote:
>
> Presumed that _all_ packages for _all_ architectures are FHS compliant
> at the moment we release 2.2. I fear, that this isn't possible if we
> want to release potato in the next half year.
>
> [and]
>
> I would prefer
Roland Rosenfeld wrote:
> So I still think that we need some interim solution until all packages
> are FHS compliant. [...]
Frankly, I think we ended up doing it this way because there wasn't one.
There have been endless discussions about the best way to do this move,
with no resolution. I'm gla
On Mon, 05 Jul 1999, Steve Greenland wrote:
> > > Agreed, users should not be forced to upgrade unnecessarily, nor
> > > accross-the-board, and we should make that as painlesl *as
> > > reasonably feasible*.
> > That's what I mean.
>
> But that's different than "without *any* drawbacks".
Englis
On 05-Jul-99, 07:49 (CDT), Roland Rosenfeld <[EMAIL PROTECTED]> wrote:
> On Sun, 04 Jul 1999, Steve Greenland wrote:
> > Agreed, users should not be forced to upgrade unnecessarily, nor
> > accross-the-board, and we should make that as painlesl *as
> > reasonably feasible*.
>
> That's what I mean
On Sun, 04 Jul 1999, Steve Greenland wrote:
> > Because Debian is the distribution, where the user can upgrade or
> > keep every single package without any drawbacks.
> ^
> Who says that?
I say this. IMHO this is one of the main advantages of Debia
Why dpnt't we simply modify debhelper and similar tools to add this to
postinst of packages: (only if upgrading from a pre-FHS version)
if [ $1 = configure -a { $2 is a previous version than 1.2 } ]; then
ln -sf ../share/$package /usr/doc/$package
fi
And it would be just adding a
On 04-Jul-99, 05:32 (CDT), Roland Rosenfeld <[EMAIL PROTECTED]> wrote:
> Because Debian is the distribution, where the user can upgrade or keep
> every single package without any drawbacks.
^
Who says that? Agreed, users should not be forced to upgrade
u
On Sat, 03 Jul 1999, Darren O. Benham wrote:
> > This is principally the right way (according to FHS), but we
> > cannot recompile all packages now but we need a smooth way from
> > one directory to the other.
> Why do we need a smooth way?
Because Debian is the distribution, where the user can
On Sat, Jul 03, 1999 at 06:44:57PM -0700, Darren O. Benham wrote:
> > This is principally the right way (according to FHS), but we cannot
> > recompile all packages now but we need a smooth way from one directory
> > to the other.
> Why do we need a smooth way? Some packages (including many of mi
On Sun, Jul 04, 1999 at 02:27:01AM +0200, Roland Rosenfeld wrote:
> This is principally the right way (according to FHS), but we cannot
> recompile all packages now but we need a smooth way from one directory
> to the other.
Why do we need a smooth way? Some packages (including many of mine at th
Package: debian-policy
Version: 3.0.0.0
Severity: important
debian-policy 3.0.0.0 is now out and mentions to use
/usr/share/doc/ instead of /usr/doc/.
This is principally the right way (according to FHS), but we cannot
recompile all packages now but we need a smooth way from one directory
to the
65 matches
Mail list logo
