|
Home > Archive > Debian Developers > September 2007 > semi-virtual packages?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
semi-virtual packages?
|
|
| Bruce Sass 2007-09-23, 7:31 am |
| On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote:
> On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass <bmsass@shaw.ca> said:
>
> But this does not address the case of a file shared by many
> packages but really owned by none.
True, but...
Since such a file is owned by none, it can not be owned by anyone.
The same solution would apply, if we could create a package for it on
the fly.
Is there any situation where ownership has collided, and a virtual
package is/(could) not (be) Provide:-ed?
[Realizing that discussion about wild ideas is far from sublime, I
decided to put some thoughts to rhyme, hope it works this time.]
[assuming a, "no", to the above... ya, both question and poetry :D ]
Perhaps virtual packages need to have a real presence on the system when
such a situation exists.
If you are willing to go for that,
and assuming dpkg triggers can be used for this kind of thing:
A package generating a file which is most properly owned by a virtual
package it Provides: could trigger, `add these paths to the list of
paths owned by <virtual package>.' Same game as above, different
package name.
- dpkg (controlled code) would need to create an entry in the DB (i.e.,
status, info/*, ...) for these semi-virtual packages, and remove/purge
them when the last package providing a virtual package is
removed/purged.
- Since these semi-virtual packages would only exist if a real package
was providing them there should be no problem with respect to
dependency calculations if they actually exist in the DB.
- I suspect a new Provided-by: field in the DB could help dpkg keep
track of what's up during failed upgrades, and if not, the frontend
tools would probably like to be able to convey the info onto users.
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-09-23, 1:33 pm |
| On Sun, 23 Sep 2007 04:13:41 -0600, Bruce Sass <bmsass@shaw.ca> said:
> On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> True, but... Since such a file is owned by none, it can not be owned
> by anyone. The same solution would apply, if we could create a
> package for it on the fly.
We can create any number of dummy packages on the fly, but what
is the use case we are trying to solve here? Why are we adding a
virtual package, having package provide the virtual package, given that
this virtual package does not provide any functionality, and so no
other package is going to depend on it?
> Perhaps virtual packages need to have a real presence on the system
> when such a situation exists.
> If you are willing to go for that,
I might be willing to go for that if there was a clear statement
of benefit gained, what use case we are satisfying, and if there were
convincing arguments that other solutions are not a better fit than
trying to shoe horn dpkg -L to be the solution to whatever use case we
are attempting to solve (this is no longer the original use case
presented -- I-do-not-know-where-the-documentation-is).
So, can we start over, and have a clear problem statement,
alternate solutions (does this move into tripwire space?), and then
decide what the preferred solution is?
manoj
--
If you ever drop your keys into a river of molten lava, let'em go,
because, man, they're gone.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2007-09-23, 7:23 pm |
| On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote:
> On Sun, 23 Sep 2007 04:13:41 -0600, Bruce Sass <bmsass@shaw.ca> said:
said:[vbcol=seagreen]
>
> We can create any number of dummy packages on the fly, but
> what is the use case we are trying to solve here? Why are we adding a
> virtual package, having package provide the virtual package, given
> that this virtual package does not provide any functionality, and so
> no other package is going to depend on it?
Why are you asking that. You provided the use case---"a file shared by
many packages but really owned by none."
I have written nothing about "adding a virtual package", and the
functionality of the existing virtual packages which I would manifest
is obvious---provide a home for the files "shared by many packages but
really owned by none."
>
> I might be willing to go for that if there was a clear
> statement of benefit gained, what use case we are satisfying, and if
> there were convincing arguments that other solutions are not a better
> fit than trying to shoe horn dpkg -L to be the solution to whatever
> use case we are attempting to solve (this is no longer the original
> use case presented -- I-do-not-know-where-the-documentation-is).
Huh. You provided the case, and the benefit should be obvious---and if
it is not then why did you bring up addressing, "the case of a file
shared by many packages but really owned by none"?
WTF does "shoe horn dpkg -L" have to do with what I wrote?
That sounds a lot like the wedging we used to do back in the early 80's
when the OS was in ROM and it wasn't practical to rewrite it. I would
hope Debian can do better than such hacks.
Ya, this is different from "I-do-not-know-where-the-documentation-is",
but then that should not be surprising since I'm not addressing that. I
did not even realize that is what the thread's originator was asking
until he clarified by answering someone who appears to have had the
same misunderstanding as I about what he was asking.
> So, can we start over, and have a clear problem statement,
> alternate solutions (does this move into tripwire space?), and then
> decide what the preferred solution is?
"tripwire", again, WTF. What I mentioned no more moves into "tripwire
space" than installing or upgrading any other package does. So, it
would be handled by whatever mechanism currently does that. Surely you
don't think the OS should cater to whatever deficiencies some app
running on it has.
I don't see any need for myself to start over. I answered Oleg's
question, and addressed your case. You, on the other hand: seem to have
forgotten what you wrote; failed to answer the one question I asked;
and brought up irrelevant stuff like, "shoe horn dpkg -L",
and "tripwire space." I think you need to start over.
Ya know, I thought that if I was really very lucky there was an outside
chance of getting a, `posts on -devel rarely make me smile, but yours
seems to have walked that mile', but if you really want to be pissy and
obtuse... I can do that too.
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-09-23, 7:23 pm |
| On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass <bmsass@shaw.ca> said:
> On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote:
[vbcol=seagreen]
> Why are you asking that. You provided the use case---"a file shared by
> many packages but really owned by none."
Yup, I provided that use case. I see no reason to create a
virtual package to implement the use case I provided.
I ask again, do you have a use case which led you down the path
of proposing a virtual package?
> I have written nothing about "adding a virtual package", and the
> functionality of the existing virtual packages which I would manifest
> is obvious---provide a home for the files "shared by many packages but
> really owned by none."
[vbcol=seagreen]
> Huh. You provided the case, and the benefit should be obvious---and if
> it is not then why did you bring up addressing, "the case of a file
> shared by many packages but really owned by none"?
No, my use case merely says that we should be able to have a
situation where we have a configuration file that does not belong to a
package. And yes, I see the benefits of this use case immediately.
> WTF does "shoe horn dpkg -L" have to do with what I wrote? That
> sounds a lot like the wedging we used to do back in the early 80's
> when the OS was in ROM and it wasn't practical to rewrite it. I would
> hope Debian can do better than such hacks.
I do not follow.
> Ya, this is different from "I-do-not-know-where-the-documentation-is",
> but then that should not be surprising since I'm not addressing
> that. I did not even realize that is what the thread's originator was
> asking until he clarified by answering someone who appears to have had
> the same misunderstanding as I about what he was asking.
I ask again, what use case are you addressing? The use case I
proposed does not need a virtual package.
[vbcol=seagreen]
> "tripwire", again, WTF.
Again?
> What I mentioned no more moves into "tripwire space" than installing
> or upgrading any other package does. So, it would be handled by
> whatever mechanism currently does that. Surely you don't think the OS
> should cater to whatever deficiencies some app running on it has.
What are these deficiencies? I see a situation, currently, where
some files belong to a particular package. They are shipped in the
.deb. Other files do not belong to the package, and are handled
separately.
Now, I suppose you are only worried about files in /etc and sch;
and not files under /var (no way to associate a lot of those files
with the packages that contain the entities that created them). The
question is, why are we trying to assign parentage to the files created
by maintainer scripts? Curiosity? or something else? Is the benefit
gained worth the cost of the solution? (a virtual package that provides
no services, and no package ever depends on, and is only there to have
a dpkg -L listing of files).
> I don't see any need for myself to start over. I answered Oleg's
> question, and addressed your case. You, on the other hand: seem to
> have forgotten what you wrote; failed to answer the one question I
> asked; and brought up irrelevant stuff like, "shoe horn dpkg -L", and
> "tripwire space." I think you need to start over.
Could we be less confrontational, perhaps?
> Ya know, I thought that if I was really very lucky there was an
> outside chance of getting a, `posts on -devel rarely make me smile,
> but yours seems to have walked that mile', but if you really want to
> be pissy and obtuse... I can do that too.
I guess you have succeeded eminently, then.
manoj
--
You are destined to become the commandant of the fighting men of the
department of transportation.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2007-09-25, 7:33 am |
| On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote:
> On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass <bmsass@shaw.ca> said:
>
> Yup, I provided that use case. I see no reason to create a
> virtual package to implement the use case I provided.
>
> I ask again, do you have a use case which led you down the
> path of proposing a virtual package?
I say again, I have not proposed creating any virtual packages...
....what I did mention was:[vbcol=seagreen]
I ask again, with slightly different words:
Is there any "case of a file shared by many packages but really owned by
none" which does not already have a virtual package associated with it?
Unfortunately, "I see no reason to create a virtual package to implement
the use case I provided.", sounds like a "yes" but it doesn't really
answer the question. I can't find a case so I can not demonstrate
something which doesn't exist, you think you've found a case so you
should be able to describe it more fully than "I see no reason".
Everything I described after that point was under: assuming a, "no".
If you would have answered "yes" to that question then you should have
ignored (at least from the perspective of solving the case you
mentioned) everything after that point because it was clearly not
applicable to your use case.
It would have then been a good idea to describe why your use case
results in a "yes" because I was, equally clearly, not able to think of
a situation including your use case which should not already involve a
virtual package. If it was otherwise I would not have assumed "no", ya.
[vbcol=seagreen]
>
> No, my use case merely says that we should be able to have a
> situation where we have a configuration file that does not belong to
> a package. And yes, I see the benefits of this use case immediately.
<aside>
it is stuff like this which tends to act like `pee in my cornflakes'
What does the "No" you wrote connect with:
- the fact that you provided the use case,
in spite of your, "Yup, I provided that use case.", statement
- the implication that benefits should be obvious to you,
since you provided the case
- is it an answer to the question itself,
even though the answer should be in the form of an explanation
- is it a denial of your own words,
which I quoted verbatim
- a claim that I've twisted the meaning of the quote somehow,
even though the only thing missing is: "But this does not address..."
?????
<shrug>
</aside>
OK. So you should be pleased I have not said anything which would take
that possibility away, or force an action from abstainers. If a
Maintainer script wants to create an orphan file it would simply
neglect to trigger after creating it.
>
> I do not follow.
I noticed.
>
>
> I ask again, what use case are you addressing? The use case I
> proposed does not need a virtual package.
Yours. The scheme I described was under the written assumption there are
no such situations which would not already have a virtual package.
Why would you think any of that scheme was applicable to the case you
were thinking of if it is a case in which there is no virtual package?
>
> Again?
having trouble following again, OK...
In the "dpkg -L" instance you are apparently criticizing the scheme
based on some fantasy implementation you have which involves, "trying
to shoe horn dpkg -L". Now, since I never mentioned any implementation
details, and especially not "dpkg -L"'s code ('cause that like a sounds
pretty hack-ish way to go about it, imo), my first response is WTF is
he going on about.
In the "tripwire" instance, you should re-read the rest of the
paragraph. I don't think I can explain it any better than that. If you
still have trouble understanding why bringing up apparently irrelevant
concerns would cause someone to think "WTF"... <shrug>
[but this may become clearer later on, so hang on a minute]
>
> What are these deficiencies? I see a situation, currently,
> where some files belong to a particular package. They are shipped in
> the .deb. Other files do not belong to the package, and are handled
> separately.
I don't know, you are the one who seems to think tripwire could be a
concern. I am simply pointing out that any program which would be a
concern because it can't handle a system upgrade must somehow be
deficient, and they should find their own solution.
> Now, I suppose you are only worried about files in /etc and
> sch; and not files under /var (no way to associate a lot of those
> files with the packages that contain the entities that created them).
I wasn't worried at all about where the files created by Maintainer
scripts would reside, just that they were being created and there was a
virtual package which could be given a real presence to claim ownership
of them via info/<package>.list.
I had considered that files under /etc which are owned by a semi-virtual
package may need special handling, but could not think of a case for
which simply not-purging the previous version before upgrading to the
next wouldn't be an adequate solution. Since that is how dpkg currently
behaves I saw no need to bring it up. The same would apply to files
under (say) /usr/share/doc/<semi-virtual package>.
With respect to the, "no way to associate", problem:
I looked at it from the other direction, so-to-speak.
- New installations would be fine.
- Upgrades should naturally result in ownership of orphan files getting
sorted out as the Maintainer scripts which manage them do their thing.
Although it may be desirable to force the issue even though the code to
do so may need to be kept around for a couple of releases.
- Whether or not it "was desirable to force" would depend on how many
orphan files were expected to be left lying around after a release
cycle. Too many and Maintainer scripts should go out of their way to
ensure everything assignable to a semi-virtual package gets assigned.
- Any orphan files still left kicking around would need to be handled on
a case-by-case basis. Too many of those, "no way to associate" =
case-by-case, files and the semi-virtual package idea is likely not
good enough.
- However, since the only files I could imagine being left out of the
above transition are ones which arrive with the initial installation of
Debian, there should not be many of them.
i.e.: afaict, it probably isn't much of a problem
Whether it would be worth creating a semi-virtual package for them would
depend on how easy it was to keep track of them at creation time, or
automatically find them afterwards, I suppose. I mean, if the
infrastructure is there because it makes sense otherwise, may as well
do it even though it is just icing.
> The question is, why are we trying to assign parentage to the files
> created by maintainer scripts? Curiosity? or something else? Is the
> benefit gained worth the cost of the solution? (a virtual package
> that provides no services, and no package ever depends on, and is
> only there to have a dpkg -L listing of files).
I figured it was mostly so that "dpkg -S" would always spit out a
result, but having "dpkg -L" be as accurate as possible is desirable
too. For me those would be good enough reasons.
dpkg-repack is an interesting case.
It appears to rely on "dpkg -L" and conffiles so could miss generated
files. It is no big deal because they should be regenerated if the
repack is re-installed, but perhaps some non-conffile configs are lost
and some reconfiguration would be eliminated if they were included.
A somewhat similar situation exists with wishlist bug #359203, instead
of generated files not being saved in the repack the submitter wants to
include, "conf files non present in the original package"
(presumably /etc/*conf.d kinda stuff). A mechanism for appending paths
to a package's .list file could satisfy the request.
With both of those cases, dpkg-repack's ability to, "store the current
state of a package before you upgrade it" would be enhanced by a more
accurate "dpkg -L".
The interesting part, imo, is if any scripts will horribly break if a
file they want to generate already exists when the repack gets
re-installed ("horribly break" as in: needing a bottom up rewrite to
accommodate the new paradigm). I don't know if that is something to
worry about though.
Cruft should also benefit from packages (or admins, ala #359203) being
able to append to <package>.list (which cruft looks at directly),
fewer "unexplained files" or perhaps simpler "explain" scripts.
So, I guess we can say that in the least it would remove a couple dpkg
warts, and improve a couple other packages.
If the only or main costs as you see them are:
- a virtual package that provides no services,
- and no package ever depends on,
- and is only there to have a dpkg -L listing of files
No virtual packages being created, the semi-virtual packages will be
depended upon by the same packages which depend on the virtual package,
and having a more accurate "dpkg -L" would be be more than
simply "nice".
> Could we be less confrontational, perhaps?
I hope so.
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-09-25, 1:28 pm |
| On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass <bmsass@shaw.ca> said:
> On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote:
[vbcol=seagreen]
> I say again, I have not proposed creating any virtual packages...
Sorry, that was not clear to me.
[vbcol=seagreen]
> ...what I did mention was:
Could you please elaborate what you mean, since I obviously have
not understood you?
[vbcol=seagreen]
> I ask again, with slightly different words: Is there any "case of a
> file shared by many packages but really owned by none" which does not
> already have a virtual package associated with it?
Sure. /etc/kernel-img.conf, if it exists, does not belong to
anyone.
> Unfortunately, "I see no reason to create a virtual package to
> implement the use case I provided.", sounds like a "yes" but it
> doesn't really answer the question. I can't find a case so I can not
> demonstrate something which doesn't exist, you think you've found a
> case so you should be able to describe it more fully than "I see no
> reason".
No, that is not what I meant. What I meant was that my use case
was that there are circumstances where it is useful to have a number of
packages read a configuration file -- but none of them really wants to
own it.
> Everything I described after that point was under: assuming a, "no".
> If you would have answered "yes" to that question then you should have
> ignored (at least from the perspective of solving the case you
> mentioned) everything after that point because it was clearly not
> applicable to your use case.
> It would have then been a good idea to describe why your use case
> results in a "yes" because I was, equally clearly, not able to think
> of a situation including your use case which should not already
> involve a virtual package. If it was otherwise I would not have
> assumed "no", ya.
Think, for instance, of kernel image packages. Kernel image
packages come and go -- each new upstream kernel creates a whole slew
of packages. Now, if any package owned the file, and the image package
was purged -- the file would go with it. So, kernel-img.conf exists
outside of any package -- and is created by some image package postinst
in certain rare conditions, and abandoned.
aside>[vbcol=seagreen]
> it is stuff like this which tends to act like `pee in my cornflakes'
Well, the misunderstanding is with what I was presenting as my
use case (need for files to not belong to any package, in the absence
of any virtual package to tack the file on to).
You were talking of something else entirely -- I think you are
talking about upgrading a free floating conf file to a different
format, or something like that (I am still not sure)
> What does the "No" you wrote connect with:
> - the fact that you provided the use case, in spite of your, "Yup, I
> provided that use case.", statement
nope.
> - the implication that benefits should be obvious to you, since you
> provided the case
nope.
> - is it an answer to the question itself, even though the answer
> should be in the form of an explanation
Err, I don't think I follow. I was asking for the benefits of
knowing which package a file belongs to, but my use case was about not
having a file belong to any package. What answer could I give?
> - is it a denial of your own words, which I quoted verbatim
> - a claim that I've twisted the meaning of the quote somehow, even
> though the only thing missing is: "But this does not address..."
> ?????
nope.
I presented a use case "Utility of a free floating conf file"
You present a case " need to know what package file belongs to"
How does the utility of you use case get tied to the utility of
my use case?
shrug>
[vbcol=seagreen]
> OK. So you should be pleased I have not said anything which would take
> that possibility away, or force an action from abstainers. If a
> Maintainer script wants to create an orphan file it would simply
> neglect to trigger after creating it.
[vbcol=seagreen]
> I noticed.
For someone complaining about lack of explanations, you are not
very forthcoming with your own.
[vbcol=seagreen]
> Yours.
Actually not. My use case is about the need of a free floating
conf file. This is not what you are describing.
> The scheme I described was under the written assumption there
> are no such situations which would not already have a virtual package.
Ah. That assumption turns out to be incorrect.
> Why would you think any of that scheme was applicable to the case you
> were thinking of if it is a case in which there is no virtual package?
I am not sure how to answer that. I assumed that the scheme
under discussion was going to be universal (or else it does not seem to
be much good, really -- it would still leave files around that are not
associated with anything).
> I don't know, you are the one who seems to think tripwire could be a
> concern. I am simply pointing out that any program which would be a
> concern because it can't handle a system upgrade must somehow be
> deficient, and they should find their own solution.
I was not aware we were talking of programs that do not handle a
system upgrade. I just thought that tripwire keeps trzck of files that
are corrupt; and wanting to know which package a file belongs to could
have been part of a systems integrity checking use case -- but that is
merely speculation on my part. What use case _is_ "knowing what package
a file belongs to" a part of?
[vbcol=seagreen]
> I wasn't worried at all about where the files created by Maintainer
> scripts would reside, just that they were being created and there was
> a virtual package which could be given a real presence to claim
> ownership of them via info/<package>.list.
And in case there is no virtual package?
> I had considered that files under /etc which are owned by a
> semi-virtual package may need special handling, but could not think of
> a case for which simply not-purging the previous version before
> upgrading to the next wouldn't be an adequate solution. Since that is
> how dpkg currently behaves I saw no need to bring it up. The same
> would apply to files under (say) /usr/share/doc/<semi-virtual
> package>.
Ah. This is not anything I was talking to.
But I see the problem: if anything were to depend on a changed
format of /etc/kernel-img.conf; there would be no pre-defined way to
manage that. No matter what you purge, that file does not go away.
What I would end up doing in that instance was to create a
Version variable in the file; and look to see if the file had a version
I could deal with, and produce a diagnostic if I did not know about
the version on disk.
In other words, the program that read the file would have to be
> With respect to the, "no way to associate", problem: I looked at it
> from the other direction, so-to-speak.
> - New installations would be fine.
Ok
> - Upgrades should naturally result in ownership of orphan files
> getting sorted out as the Maintainer scripts which manage them do
> their thing. Although it may be desirable to force the issue even
> though the code to do so may need to be kept around for a couple of
> releases.
Umm. Not if no package can take ownership.
> - Whether or not it "was desirable to force" would depend on how many
> orphan files were expected to be left lying around after a release
> cycle. Too many and Maintainer scripts should go out of their way to
> ensure everything assignable to a semi-virtual package gets assigned.
If the file was meant to be lying around, it would remain so.
> - Any orphan files still left kicking around would need to be handled
> on a case-by-case basis. Too many of those, "no way to associate" =
> case-by-case, files and the semi-virtual package idea is likely not
> good enough.
I am not sure how many there are. I am aware of one that my
packages create. I assume there might be others.
> - However, since the only files I could imagine being left out of the
> above transition are ones which arrive with the initial installation
> of Debian, there should not be many of them.
> i.e.: afaict, it probably isn't much of a problem
> Whether it would be worth creating a semi-virtual package for them
> would depend on how easy it was to keep track of them at creation
> time, or automatically find them afterwards, I suppose. I mean, if the
> infrastructure is there because it makes sense otherwise, may as well
> do it even though it is just icing.
So you _are_ talking about creating virtual packages in some
cases?
[vbcol=seagreen]
> I figured it was mostly so that "dpkg -S" would always spit out a
> result, but having "dpkg -L" be as accurate as possible is desirable
> too. For me those would be good enough reasons.
If a file does not belong to any package, then it should not
> If the only or main costs as you see them are:
> - a virtual package that provides no services,
> - and no package ever depends on,
> - and is only there to have a dpkg -L listing of files
> No virtual packages being created, the semi-virtual packages will be
> depended upon by the same packages which depend on the virtual
> package, and having a more accurate "dpkg -L" would be be more than
> simply "nice".
Except in this case there is no virtual package that anyone
depends on.
manoj
--
"Maybe we can get together and show off to each other sometimes."
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2007-09-26, 7:34 am |
| On Tue September 25 2007 09:22:02 am Manoj Srivastava wrote:
> On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass <bmsass@shaw.ca> said:
[I've cut a lot of duplication. If I cut something which doesn't get addressed below, feel free to bring it back.]
[vbcol=seagreen]
>
> Ah. That assumption turns out to be incorrect.
Haha. There is nothing wrong with the assumption. That is kinda like saying pylint is incorrect for spitting out errors when given a correct PERL program. You ignored a sign which would have taken you down a different path, and now appear to be complainin
g because the path you ended up on took you to the wrong place---neither the sign or paths are incorrect, you just didn't pay attention and got lost.
>
> I am not sure how to answer that. I assumed that the scheme
> under discussion was going to be universal (or else it does not seem
> to be much good, really -- it would still leave files around that are
> not associated with anything).
I don't see why it would need to be universal, "one size" stuff often doesn't fit anyone very well and it is not like being universal is pervasive and this would stand out as a wart.
I think I see where you are getting confused though.
On the one hand you seem to be saying there are files that should be orphans (e.g.: /etc/kernel-img.conf), yet you criticize the scheme for not being universal. Why does not being universal "not seem to be much good" if you actually don't want universalit
y because you know of files which shouldn't or can't be owned by a package?
You did the same sorta thing earlier. Your initial post seemed to be *faulting* a scheme to append paths to <package>.list for not addressing "the case of a file shared by many packages but really owned by none", yet later on you state: "my use case merel
y says that we should be able to have a situation where we have a configuration file that does not belong to a package". Why should a scheme to add files generated by a package to its own <package>.list need to address the case of files without packages t
hat don't want to be owned?
The way I see it, from a logical pov, you can resolve the contradictions by giving up the premise of universality. Once you do that, the opt-in nature of the mechanism takes care of /etc/kernel-img.conf and like, trivially (nothing more trivial than doing
nothing, eh).
> What use case _is_ "knowing what package a file belongs to" a part of?
"dpkg -S" (and any programs which use it) , cruft, idle curiosity, ...
>
> And in case there is no virtual package?
status quo
>
> Ah. This is not anything I was talking to.
I knew that. It is just more info which may help resolve the problems.
> But I see the problem: if anything were to depend on a
> changed format of /etc/kernel-img.conf; there would be no pre-defined
> way to manage that. No matter what you purge, that file does not go
> away.
[ignoring that kernel-img.conf doesn't have to opt-in, so handling that situation could be as it is now]
Uhm, that is only a problem if a file is not owned by a package. This thread has been about a mechanism which could add such orphan files to a package so they can be listed, search for, removed, purged, or whatever else one (admin or program) does with th
at relationship.
Maybe this wasn't as clear as I thought:
A semi-virtual package is virtual to Debian and real on a user's system, so an admin always has the option of manually remove/purge-ing whatever they end up owning. During normal operation that sort of thing would be handled automatically as the packages
Provide:-ing the semi-virtual ones get manipulated.
> What I would end up doing in that instance was to create a
> Version variable in the file; and look to see if the file had a
> version I could deal with, and produce a diagnostic if I did not know
> about the version on disk.
>
> In other words, the program that read the file would have to
> be
[you forgot to finish this thought, sorry if I miss the point...]
Packages would need to manage their own creations, just as it is now.
What would change is that if a script triggers the addition of a generated path to a package's .list, it will no longer need to manually remove that path when it gets purged. So, a little less work for most(?) Maintainer scripts which generate files!
>
> Ok
>
>
> Umm. Not if no package can take ownership.
no harm, no foul?
>
> If the file was meant to be lying around, it would remain so.
A good thing, ya?
>
> I am not sure how many there are. I am aware of one that my
> packages create. I assume there might be others.
Probably, but since you don't want yours (/etc/kernel-img.conf, I'm assuming) to be owned by a package it is immaterial wrt to deciding if the scheme is feasible or not. The only ones which count are those which would want to be owned except an owner can
not be determined.
>
> So you _are_ talking about creating virtual packages in some
> cases?
No. The package would be real, the only difference would be that instead of being downloaded it would be created locally.
>
> If a file does not belong to any package, then it should not
[I suspect that is a much stronger statement than you intended, or perhaps an incomplete thought. If taken as written, assuming the only thing missing is a period, it flies in the face of history (see: http://lists.debian.org/debian-policy/1998/04/msg0008
9.html) and at least a few bugs (#85960, #213907, #359203)... it borders on absurdity, imo.]
If a package wants a file it creates to be an orphan it can continue to do so,...
>
> Except in this case there is no virtual package that anyone
> depends on.
....if a file has no choice but to be an orphan then, <shrug>, at least it is no worse off than it was. The only problem I see wrt what cases are being properly handled is if there are a lot of files which want to be owned but for some reason can't be XXX
ign ownership. That would indicate the solution isn't good enough, at least on its own.
- Bruce
| |
| Manoj Srivastava 2007-09-27, 7:38 am |
| On Wed, 26 Sep 2007 04:04:33 -0600, Bruce Sass <bmsass@shaw.ca> said:
> On Tue September 25 2007 09:22:02 am Manoj Srivastava wrote:
[vbcol=seagreen]
> [I've cut a lot of duplication. If I cut something which doesn't get
> addressed below, feel free to bring it back.]
[vbcol=seagreen]
> Haha. There is nothing wrong with the assumption. That is kinda like
> saying pylint is incorrect for spitting out errors when given a
> correct PERL program. You ignored a sign which would have taken you
> down a different path, and now appear to be complaining because the
> path you ended up on took you to the wrong place---neither the sign or
> paths are incorrect, you just didn't pay attention and got lost.
Hmm? You assumed, and I quote "there are no such situations
which would not already have a virtual package". Since there are
situations where there is no virtual package, it certainly seems to me
that the assumption you made is invalid.
If your assumption is correct, then I have missed something
somewhere.
[vbcol=seagreen]
> I don't see why it would need to be universal, "one size" stuff often
> doesn't fit anyone very well and it is not like being universal is
> pervasive and this would stand out as a wart.
If we are not talking about a policy to be made, and you are
only talking about an opt in scheme for some orphan files, then
indeed, I have nothing to add to the conversation.
manoj
--
algorithm, n.: Trendy dance for hip programmers.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2007-09-27, 1:36 pm |
| On Thu September 27 2007 01:33:21 am Manoj Srivastava wrote:
> On Wed, 26 Sep 2007 04:04:33 -0600, Bruce Sass <bmsass@shaw.ca> said:
> Hmm? You assumed, and I quote "there are no such situations
> which would not already have a virtual package". Since there are
> situations where there is no virtual package, it certainly seems to
> me that the assumption you made is invalid.
That is not correct, what I assumed was:
a, "no", to the above [question]
What you quoted is not a primary assumption (as you've been treating it
as), it is based on a condition having been met.
> If your assumption is correct, then I have missed something
> somewhere.
The bit you're still missing is the first part of the question you
didn't answer: "Is there any situation where ownership has collided"
IOW: if the file shared by many packages isn't having ownership problems
there is no need to consider it (no point trying to fix something that
is not broken, eh).
>
> If we are not talking about a policy to be made, and you are
> only talking about an opt in scheme for some orphan files, then
> indeed, I have nothing to add to the conversation.
s/some/all but a few/ I suspect
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-09-27, 7:38 pm |
| On Thu, 27 Sep 2007 08:08:49 -0600, Bruce Sass <bmsass@shaw.ca> said:
> The bit you're still missing is the first part of the question you
> didn't answer: "Is there any situation where ownership has collided"
> IOW: if the file shared by many packages isn't having ownership
> problems there is no need to consider it (no point trying to fix
> something that is not broken, eh).
The start of this thread was a rant about not loose files
floating around in /etc; not necessarily about whether these files in
themselves had ownership problems (whtever that means).
Here is the original context. Note how you say the problem
(actually, design flaw) is about current tools do not "catch files
created by Maintainer scripts"?
Nice to see the design flaw has become stuff that is not broken
and does not have to be fixed. That is all I cared about, really.
manoj
On Fri, 21 Sep 2007 03:25:23 +0000 (UTC), Oleg Verych (Gmane)
<!gmane?olecom.ENOMSG@flower.upol.cz> said:
> 19-09-2007, Bruce Sass: []
[vbcol=seagreen]
> This is the design flaw in those scripts (even in whole package
> management).
--
You know how to win a victory, Hannibal, but not how to use it. Maharbal
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2007-09-28, 1:32 am |
| On Thu September 27 2007 05:38:53 pm Manoj Srivastava wrote:
> On Thu, 27 Sep 2007 08:08:49 -0600, Bruce Sass <bmsass@shaw.ca> said:
>
> The start of this thread was a rant about not loose files
> floating around in /etc; not necessarily about whether these files
> in themselves had ownership problems (whtever that means).
>
> Here is the original context. Note how you say the problem
> (actually, design flaw) is about current tools do not "catch files
> created by Maintainer scripts"?
>
> Nice to see the design flaw has become stuff that is not
> broken and does not have to be fixed. That is all I cared about,
> really.
Oleg considers it a design flaw, I have stated no such opinion and
didn't even include his statement to that effect in my reply. Why would
you bring it up... grasping at straws, perhaps.
The original context I was responding to, and which you jumped in on, is
this:
-----
On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass <bmsass@shaw.ca> said:
> On Sat September 22 2007 12:16:18 am Oleg Verych (Gmane) wrote:
[vbcol=seagreen]
> It is not feasible (imo) to automatically find files created by
> maintainer scripts. Having packages append <package>.list themselves
> would (afaict) require they know too much about dpkg's internal
> operation, and all packages generating files would need to implement
> the algorithm.
> However, maintainer scripts can easily pass a list of generated paths
> on to a shared piece of code which dpkg controls. "triggers" looks
> like it could be the mechanism by which a package flags that it has
> generated files, and by which dpkg exerts control.
But this does not address the case of a file shared by many
packages but really owned by none.
manoj
-----
You then proceeded to demonstrate that you: have trouble reading,
following arguments, keeping track of what your own use case actually
is, and using logic. You are now finishing up with misquotes and
misrepresentation of anothers position. Do you wonder why you get in
so many fights and pointless arguments. :-/
Bye-bye, and I wish you luck in whatever little fantasy world you've
constructed for yourself.
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2007-09-28, 7:22 pm |
| Someone wrote:
> If you actually need to make this sort of response, could you do the
> rest of us a favor and not do so publicly?
Ya, you're right. Sorry.
My frustration got the better of me.
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|