[gentoo-dev] dummy-sources

[gentoo-dev] dummy-sources

[Florian Huber]

Hello,
since I am mostly using custom patched kernels I do not want to
install any gentoo-provided kernel package.

It would be a great idea if there was a ebuild like "dummy-sources"
which only provides virtual/linux-sources.

Bye
	Florian Huber

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Dave Nellans]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

this is why the -i (inject) option exists... do emerge -i
sys-kernel/vanilla-sources and portage will "think" it is installed. 
you are then free to use whatever sources you please without having
sources flying around your /usr/src.  see man portage for further info

dave

On Thu, 2003-07-24 at 08:43, Florian Huber wrote:
> Hello,
> since I am mostly using custom patched kernels I do not want to
> install any gentoo-provided kernel package.
> 
> It would be a great idea if there was a ebuild like "dummy-sources"
> which only provides virtual/linux-sources.
> 
> Bye
> 	Florian Huber
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Dave Nellans
http://lucy.wox.org/~dnellans/
dnellans@cs.utah.edu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] dummy-sources

[Thomas de Grenier de Latour]

On 24 Jul 2003 08:59:28 -0600
Dave Nellans <dnellans@cs.utah.edu> wrote:

> this is why the -i (inject) option exists... do emerge -i
> sys-kernel/vanilla-sources and portage will "think" it is installed. 

But you have to give an explicit version to inject, and (tell me if
I'm wrong) this stub will be updated by a real package when a new
version is available, unless you mask ">sys-kernel/vanilla-sources-ver".

It would be handier if portage was able to handle this:
 # emerge inject virtual/linux-sources

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Florian Huber]

On 24 Jul 2003 08:59:28 -0600
Dave Nellans <dnellans@cs.utah.edu> wrote:

> this is why the -i (inject) option exists... do emerge -i
> sys-kernel/vanilla-sources and portage will "think" it is installed.

I know that there is the inject option, but I do not want to inject
every new vanilla-kernel version. AFAIK the inject option requires
also the ebuild version.

Bye
	Florian Huber

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Dave Nellans]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

you explicitly inject some version but as long as you never add it to
your world file it won't be updated unless required by something that
depends on it.  And in that case you are going to want to update
anyways, and you can just inject it again and build your own source that
satisfies the new dependancies.

dave

On Thu, 2003-07-24 at 09:13, Thomas de Grenier de Latour wrote:
> On 24 Jul 2003 08:59:28 -0600
> Dave Nellans <dnellans@cs.utah.edu> wrote:
> 
> > this is why the -i (inject) option exists... do emerge -i
> > sys-kernel/vanilla-sources and portage will "think" it is installed. 
> 
> But you have to give an explicit version to inject, and (tell me if
> I'm wrong) this stub will be updated by a real package when a new
> version is available, unless you mask ">sys-kernel/vanilla-sources-ver".
> 
> It would be handier if portage was able to handle this:
>  # emerge inject virtual/linux-sources
-- 
Dave Nellans
http://lucy.wox.org/~dnellans/
dnellans@cs.utah.edu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] dummy-sources

[Georgi Georgiev]

On 24/07/2003 at 17:15:46(+0200), Florian Huber used 0.4K just to say:
> On 24 Jul 2003 08:59:28 -0600
> Dave Nellans <dnellans@cs.utah.edu> wrote:
> 
> > this is why the -i (inject) option exists... do emerge -i
> > sys-kernel/vanilla-sources and portage will "think" it is installed.
> 
> I know that there is the inject option, but I do not want to inject
> every new vanilla-kernel version. AFAIK the inject option requires
> also the ebuild version.

What about

emerge --inject sys-kernel/vanilla-sources-2.4.99

This should keep you running for a while.

-- 
(*   Georgi Georgiev   (* The man who sets out to carry a cat by its   (*
*)    chutz@gg3.net    *) tail learns something that will always be    *)
(*  +81(90)6266-1163   (* useful and which never will grow dim or      (*
*) ------------------- *) doubtful. -- Mark Twain                      *)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Thomas de Grenier de Latour]

On 24 Jul 2003 09:24:17 -0600
Dave Nellans <dnellans@cs.utah.edu> wrote:

> you explicitly inject some version but as long as you never add it to
> your world file it won't be updated unless required by something that
> depends on it.  And in that case you are going to want to update
> anyways, and you can just inject it again and build your own source
> that satisfies the new dependancies.

If pkgA depends on virtual/foo, and virtual/foo is instanciated by pkgB,
then an "emerge -u pkgA" will try to update pkgB, whether it has been
really emerged  or injected. Hence, if pkgA is a world package, an
"emerge -u world" can build an update of your injected package, and in
the linux-source example, that's not what we want.

Another issue is that the inject of pkgB to instanciate virtual/foo will
only does what we expect if pkgB is the default package associated to
virtual/foo in your profile "virtuals" dictionnary. This is because
ebuilds are not parsed by inject (hence PROVIDE is ignored, and nothing
gets added to your edb/virtuals). For instance, because gentoo-sources
is the default value for virtual/linux-sources, if you inject
vanilla-sources and then emerge something depending on
virtual/linux-sources, gentoo-sources will be emerged.

That's why I was suggesting the possibility to inject virtual packages,
I think it would really be more clear when what the user wants is to
satisfy the dependencies on this virtual packages. 

But dummy ebuilds are also an acceptable (and easier) way to do it. We
can imagine a dummy category for such stub ebuilds, one for each virtual
packages, so that "emerge dummy/linux-sources" would definitly
instanciate virtual/linux-sources, because there would be no updates in
this category.

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[George Shapovalov]

Ok, there have been a few replies and well, injecting some official (i.e. 
in-portage) kernel sources may not be the ideal solution. However looks like 
nobody mentioned the following, so I'll take a shot:

Let go back to the purpose. User wants to patch together his own kernel, 
configure and install it, all in all is not a 5 min undertaking. What about 
then just creating some dummy-sources under PORTAGE_OVERLAY? (make sure that 
ebuild has PROVIDE=virtual/linux-sources, or just inherit kernel instead) 
This will only take a minute and will only add to the process that is already 
manual and best of all - you need to do it only once.
If you want to be really fancy (but depending on where you start and what 
patches you want to apply it may even save some time in the future) you can 
even create your own ebuild ;) instead of just dummy one.

In short, I think in this case (and for this particular purpose) providing 
central dummy-sources does not significantly help already simple ask. However 
I agree that generic dummy-package's may be usefull in certain situations, 
but then lets may be wait until another situation that warrants it comes 
aroung?

George


On Thursday 24 July 2003 07:43, Florian Huber wrote:
> Hello,
> since I am mostly using custom patched kernels I do not want to
> install any gentoo-provided kernel package.
>
> It would be a great idea if there was a ebuild like "dummy-sources"
> which only provides virtual/linux-sources.
>
> Bye
> 	Florian Huber
>
> --
> gentoo-dev@gentoo.org mailing list



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Mike Frysinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

this doesnt work as well as it should ...
root@rux0r 0 vmware-workstation # emerge -i sys-kernel/vanilla-sources-3.4.21
>>> Injected sys-kernel/vanilla-sources-3.4.21.
root@rux0r 0 vmware-workstation # emerge vanilla-sources -up

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild     U-] sys-kernel/vanilla-sources-2.4.21 [3.4.21] 

i agree with the original poster on this ... normally i'd tell you to inject 
it, but i'd make an exception for the kernel sources ...

so !  last call, does anyone really trully hate the idea of dummy-sources ?  
if not i'm going to go ahead and add it to the tree
- -mike

On Thursday 24 July 2003 11:37, Georgi Georgiev wrote:
> On 24/07/2003 at 17:15:46(+0200), Florian Huber used 0.4K just to say:
> > On 24 Jul 2003 08:59:28 -0600
> >
> > Dave Nellans <dnellans@cs.utah.edu> wrote:
> > > this is why the -i (inject) option exists... do emerge -i
> > > sys-kernel/vanilla-sources and portage will "think" it is installed.
> >
> > I know that there is the inject option, but I do not want to inject
> > every new vanilla-kernel version. AFAIK the inject option requires
> > also the ebuild version.
>
> What about
>
> emerge --inject sys-kernel/vanilla-sources-2.4.99
>
> This should keep you running for a while.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iQIVAwUBPyHg8kFjO5/oN/WBAQKY+xAArHKLDVDqNWuJeQs+hlwKLWGozcSRDcd4
1PVbW7mGsfkPuxVPLg1vgONJmQadgaSuBVV1pwVzxXPluukaRsNElcLaGiREF8FO
V8ZCBuFbidkHbDIhLMK5qY+Keo8SUhu5i4KBdZNapMyuO88SQhVq0P7EIsHwWbUb
0YnOQXxE58bQrq5xfG2dXYu2HJ/fl3O/XQbsExaHw60lhf/MOm4aIaJMhIm9wuMK
d8yE0nKZf7YatfGgQaOubb8mqoeG6nNVkpMOwxbijIW/8tUT2VdiL5nb/FwEOJ8n
hmcRG67jaR8MmethLQuAaqAb248FbTUoJxb4Wg/4t5BXEBYyF/OPnX40zRyQnbg1
quxUDwTK+28qfI39BS+KwsPErvxcLquwe2QVWdZp+Rij42GM9+wPZLq6rZQGPubs
eglVJBgto9m/ffMcD8CfmOAbafc1YBVKo1g3oLA6vyc800sf3CdvmQRwr0wB1Fj3
syTIHpoJqXIOopSJwZt8eD2adXnDISiOeKYiCTDzDuyDdn1q6ShosPMXnaAPiMTL
10X7PnbGKY8F83PNYhonNpCgghAQMK7dWrKD18ZZVOuGRiQc7mh3lDzwCBzAIisv
MfufoGmBjDJSZuQJxxZeGCn3OrsrxloqJBwzSs4HDLc3iKNPJ5Vl1IeWoInO6IgK
DZ3a7zlTIw0=
=lMu1
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Brad Laue]

Mike Frysinger wrote:
> so !  last call, does anyone really trully hate the idea of dummy-sources ?  
> if not i'm going to go ahead and add it to the tree
> - -mike

It doesn't make any sense. If the original poster uses custom-patched 
kernels, surely he can create his custom-patches against vanilla-sources?

It seems to me that dummy-sources would be duplicating emerge -i 
functionality if no true sources are to be installed, and would be 
duplicating vanilla-sources if untouched sources are to be installed.

Brad


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Dave Nellans]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

I agree with brad, I proposed the emerge inject solution was how this
problem was intended to be dealt with but couldn't quite make sense of
the reason this didn't work from the thread.

could someone possibly clearly give the arguement against injecting
again for us slow people?

dave

On Fri, 2003-07-25 at 20:22, Brad Laue wrote:
> Mike Frysinger wrote:
> > so !  last call, does anyone really trully hate the idea of dummy-sources ?  
> > if not i'm going to go ahead and add it to the tree
> > - -mike
> 
> It doesn't make any sense. If the original poster uses custom-patched 
> kernels, surely he can create his custom-patches against vanilla-sources?
> 
> It seems to me that dummy-sources would be duplicating emerge -i 
> functionality if no true sources are to be installed, and would be 
> duplicating vanilla-sources if untouched sources are to be installed.
> 
> Brad
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Dave Nellans
http://lucy.wox.org/~dnellans/
dnellans@cs.utah.edu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] dummy-sources

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

On 25/07/2003 at 21:26:31(-0600), Dave Nellans used 1.4K just to say:
> I agree with brad, I proposed the emerge inject solution was how this
> problem was intended to be dealt with but couldn't quite make sense of
> the reason this didn't work from the thread.
> 
> could someone possibly clearly give the arguement against injecting
> again for us slow people?

The problems as I get them, are:

- Injecting the sources, would work, but it would require reinjecting every
  newer version, or else an "emerge -u" would upgrade the version for us, when
  for example upgrading a package that depends on the sources.

- Injecting a sufficiently big, non-existing version would not work, because an
  emerge -u (even -U) would downgrade the version to the highest available,
  i.e. it would install a version.
 
It seems that having a dummy-sources whose version does not change would solve
this problem.

-- 
\    Georgi Georgiev   \  IBM's original motto: Cogito ergo vendo;     \
/     chutz@gg3.net    /  vendo ergo sum.                              /
\   +81(90)6266-1163   \                                               \

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] dummy-sources

[Dave Nellans]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

ok, that makes more sense now.

what happened to the suggested solution a few emails ago that in this
case the user should just create their own dummy-sources ebuild of
sufficiently high version and keep it in their local overlay tree?
 
while this is a legitimate grip of the portage system because it is not
convienent to do this, portage "does" have what i see as a solution, its
just not as convenient as one might want it.

so the question is should portage change to make this easier as per
suggested below.  i vote no because if we make a "dummy-XXX" then one
could argue that every package should have a dummy-* build for it. in
the long run i'm sure some user will write the dummy-* build for most
packagse in portage and that would significantly grow (everyone agree?)
the size of the tree as a solution that is for convenience.

dave
On Fri, 2003-07-25 at 22:34, Georgi Georgiev wrote:
> On 25/07/2003 at 21:26:31(-0600), Dave Nellans used 1.4K just to say:
> > I agree with brad, I proposed the emerge inject solution was how this
> > problem was intended to be dealt with but couldn't quite make sense of
> > the reason this didn't work from the thread.
> > 
> > could someone possibly clearly give the arguement against injecting
> > again for us slow people?
> 
> The problems as I get them, are:
> 
> - Injecting the sources, would work, but it would require reinjecting every
>   newer version, or else an "emerge -u" would upgrade the version for us, when
>   for example upgrading a package that depends on the sources.
> 
> - Injecting a sufficiently big, non-existing version would not work, because an
>   emerge -u (even -U) would downgrade the version to the highest available,
>   i.e. it would install a version.
>  
> It seems that having a dummy-sources whose version does not change would solve
> this problem.
-- 
Dave Nellans
http://lucy.wox.org/~dnellans/
dnellans@cs.utah.edu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] dummy-sources

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Fri, 25 Jul 2003 22:01:22 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> i agree with the original poster on this ... normally i'd tell you to
> inject it, but i'd make an exception for the kernel sources ...
> 
> so !  last call, does anyone really trully hate the idea of
> dummy-sources ?  if not i'm going to go ahead and add it to the tree
> - -mike
> 

I do object. I'd rather that the kernel people dealt with this (since
the matter falls into the kernel herd). Jay & the kernel folks?


-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://dev.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] dummy-sources

[Jason A. Mobarak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Perhaps this could be remedied a new portage option:

- --omit vanilla-sources

Not sure how feasible this is though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/IjHAVu24D/vyzbgRAn0bAJ9cGrn/MddRMKaMCEceTTtYWIbbdwCfYWjA
w2R8F6XtHvplnfgP3SqBobg=
=kw4m
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Thomas de Grenier de Latour]

On Fri, 25 Jul 2003 23:20:24 -0700
Seemant Kulleen <seemant@gentoo.org> wrote:

> 
> I do object. I'd rather that the kernel people dealt with this (since
> the matter falls into the kernel herd). Jay & the kernel folks?

The problem concerns all virtual packages, so I don't see why it should
be solved only for kernel-sources. What about a "vir-dummy" package
category, with one dummy package for each virtual package? It's really
three lines of bash code to create it.

And what about adding to emerge the possibility to inject virtual
packages? I really see this solution as the cleanest one, and most
coherent with what as been done for real package. I mean, "inject" is "a
way to satisfy a dependency with one single command, without eemerging
anything". Imho, it makes sense to be able to do it for virtuals.

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Bartosch Pixa]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

hmm, where's the problem with injecting vanilla and then either pinning
it in "world" or puting higher versions in /etc/portage/package.mask ?

-- 
Bartosch Pixa
Gentoo Linux Developer                    http://www.gentoo.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] dummy-sources

[Jay Pfeifer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't like the idea. I do not want a sys-kernel/dummy-sources in our tree. 
Using PORTDIR_OVERLAY would be best. The person can create an ebuild for 
their sources (custom patched stuff) or just make some little ebuild and 
inject it. However *they* want to handle it for their local tree is their 
choice. However adding it to our tree is not a solution I would be willing to 
offer nor support.

Jay

On Friday 25 July 2003 09:01 pm, Mike Frysinger wrote:
>
> so !  last call, does anyone really trully hate the idea of dummy-sources ?
> if not i'm going to go ahead and add it to the tree
> -mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/I+fQe5xY3v0FhjgRAgtAAKCq/maGeiSsK4rWNPozmUhDUGpLnwCeNy39
TtKEF6ijNTMnpWe3TGP/s9I=
=I/Lb
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] dummy-sources

[Florian Huber]

Finally I have just added a dummy-sources ebuild to bugzilla.

See http://bugs.gentoo.org/show_bug.cgi?id=25374

I tested it on my computer and it worked for me and it is so small
that I do not exspect bugs/problems, but nevertheless there might be
an error, because it's my first ebuild.

--
gentoo-dev@gentoo.org mailing list