Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Are you using USE-dynamic SLOTs?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  

Are you using dynamic SLOTs?
I use dynamic slots, and it would affect my workflow if they were no longer available in the main tree (please explain)
4%
 4%  [ 1 ]
I use dynamic slots, but such ebuilds could be in an overlay
0%
 0%  [ 0 ]
I don't use dynamic slots
58%
 58%  [ 14 ]
Dynamic slots? What's that?
37%
 37%  [ 9 ]
Total Votes : 24

Author Message
ulm
Developer
Developer


Joined: 04 Oct 2004
Posts: 98
Location: Mainz, Germany

PostPosted: Sat Feb 01, 2014 10:54 am    Post subject: Are you using USE-dynamic SLOTs? Reply with quote

Some ebuilds in the Portage tree use so-called dynamic slots, so they appear as slotted packages if the "multislot" USE flag is set. This affects mainly autoconf, binutils, and gcc. For example, with USE=multislot, autoconf versions 2.68 and 2.69 will appear in separate SLOTs (and can therefore be installed simultaneously). In cases where packages are already slotted – e.g., gcc has a slot for each major release version (4.7.x, 4.8.x) – multislot enables further slotting of minor versions, such as 4.8.1 and 4.8.2.

The problem with this approach is that it breaks invariance of the metadata cache which requires a static SLOT variable, independent of any user configuration. See bugs 174184 and 174407 and the Package Manager Specification for details.

The QA team has discussed the issue at a recent meeting and one possible option would be to move the use of this feature to an overlay. We are conducting this poll to find out if removal of dynamic slots from the main tree would break anybody's workflow.

Made sticky. -- desultory
Unstuck 2014 Feb 18. — JRG
Back to top
View user's profile Send private message
Hypnos
Advocate
Advocate


Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent

PostPosted: Sat Feb 01, 2014 1:51 pm    Post subject: Reply with quote

What is the use case for multislot?

Hell, what is the use case for subslots?
_________________
Personal overlay | Simple backup scheme
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Feb 03, 2014 5:31 am    Post subject: Reply with quote

Hypnos wrote:
What is the use case for multislot?

Toolchain development: not needed for the main tree, imo, since it breaks the whole slotting mechanism. (Hard-masked by name is much simpler afaict.)
Quote:
Hell, what is the use case for subslots?

They're a misfeature: basically they're yet another workaround for lack of clean LDEPEND, because doing that would mean admitting we missed a gaping hole in our work for all these years. They're fine as an implementation-level specification, but they shouldn't be in the ebuild format, imo. Perhaps for their original use-case of java and ruby libraries, though I'd argue those are better done as LDEPEND too. That gives scope for adding recursive subslots much more cleanly.

The HDEPEND bug wouldn't even exist if we'd had a LIB_DEPEND from the start, when portage was first designed based on BSD. Nor would we have all those CDEPEND workarounds, nor indeed needed revdep-rebuild. All those wasted cycles.. ;)
Back to top
View user's profile Send private message
Hypnos
Advocate
Advocate


Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent

PostPosted: Mon Feb 03, 2014 6:34 am    Post subject: Reply with quote

steveL,

Thanks for the explanation. Yes, an LDEPEND implementation would obviate post factum revdep-rebuilds, and then CDEPEND could do the job instead of HDEPEND. It seems that subslots are a useful workaround.

As for multislot, I'm not yet convinced of its usefulness. Why do people need GRUB1 and GRUB2 simultaneously, or multiple minor versions of gcc ?
_________________
Personal overlay | Simple backup scheme
Back to top
View user's profile Send private message
sera
Retired Dev
Retired Dev


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Mon Feb 03, 2014 6:55 am    Post subject: Reply with quote

steveL wrote:
Hypnos wrote:
Hell, what is the use case for subslots?

They're a misfeature: basically they're yet another workaround for lack of clean LDEPEND, because doing that would mean admitting we missed a gaping hole in our work for all these years. They're fine as an implementation-level specification, but they shouldn't be in the ebuild format, imo. Perhaps for their original use-case of java and ruby libraries, though I'd argue those are better done as LDEPEND too. That gives scope for adding recursive subslots much more cleanly.


Subslots can be emulated using slots and blockers. Syntax sugar if you want. I agree on the misfeature bit as it makes developers live easier by burdening the users. Still you got some misconception there, if a Java package makes use of subslots it's a bug.


Ulm, as for multislot, move it out of my sight and I'm happy.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Feb 03, 2014 6:59 am    Post subject: Reply with quote

Hypnos wrote:
Yes, an LDEPEND implementation would obviate post factum revdep-rebuilds, and then CDEPEND could do the job instead of HDEPEND. It seems that subslots are a useful workaround.

Hmm? Not quite: LDEPEND covers all three; not that an ebuild couldn't have additional CDEPENDs but:
a) they are usually libraries, and b) the rest don't need any special handling beyond bash scripting.

Yes, post-facto, but it was pointed out a few years ago, and it baffles me that no-one saw it in the original ports specification.

I can understand drobbins wanting to just merge "everything required at build-time": if you think of the process, both LDEPEND and DEPEND (=BUILD_DEPEND) must be installed by the package manager before you even think of running the ebuild declaring them. But everyone who's come afterward, with all that posturing on the mailing-lists taking up years of man-hours? Leave alone all the link breakages, and cross-compile headaches. Extraordinary.

Gentoo is still the best, most robust Linux distro though :)
Quote:
As for multislot, I'm not yet convinced of its usefulness. Why do people need GRUB1 and GRUB2 simultaneously, or multiple minor versions of gcc ?

Well leave aside the first, as I think it is wise to be able to mask by major-slot, users don't need multislot at all: just occasionally it's useful for development, typically in a test setup. And it can be done much simpler, with the same ebuild for both, via package naming, since it's only really needed for hard-masked toolchain packages, and experiments.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Feb 03, 2014 7:11 am    Post subject: Reply with quote

sera wrote:
Subslots can be emulated using slots and blockers. Syntax sugar if you want. I agree on the misfeature bit as it makes developers live easier by burdening the users.

Yeah: where users == ebuild authors, and developers == PMS authors. It doesn't make the package-manager developer's life easier to have the implementation detail exposed in the ebuild like that. A clean format is always easier for everyone over the longer-term, and it's simple to specify that any LDEPEND is a subslot dep: it's kinda the minimum thing you need, though if we'd had that we'd have been working with sonames and ldd (or lddtree nowadays); tracking ABI breakage vs soname and feeding that info back much quickly since it'd have been automated, instead of wasting time with excess revdep-rebuilds (as useful a safety-net as that is.)
Quote:
Still you got some misconception there, if a Java package makes use of subslots it's a bug.

Not at all: it's what they were originally proposed for, along with Ruby istr. Then when CiaranM was asked about better lib-handling, he realised the same concept applied. So in effect, as with C++ doing LISP the long way round, the PMS did the same thing: the concept was recognised, after the blatantly obvious was ignored, then rushed in with an arcane syntax foisted on the rest of us.

I cba to search the mailing-list to find it, but I distinctly recall the discussion. I quoted it on IRC at the time.
Back to top
View user's profile Send private message
Hypnos
Advocate
Advocate


Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent

PostPosted: Mon Feb 03, 2014 7:27 am    Post subject: Reply with quote

steveL wrote:
Hmm? Not quite: LDEPEND covers all three; not that an ebuild couldn't have additional CDEPENDs but:
a) they are usually libraries, and b) the rest don't need any special handling beyond bash scripting.

Sorry, I don't understand your comment. Let me explain my understanding:

In FreeBSD, there are various *_DEPENDS variables for various Ports functions (patching, fetching, etc.). drobbins decided collapse all but of of them in DEPEND, with only RUN_DEPENDS left for RDEPEND. We find now that LIB_DEPENDS would have been useful to keep separate as well, to avoid haphazardly rebuilding broken dependent packages after a dependency is upgraded.

Then, with CDEPEND, we can specify additional tools needed on the build host. We don't need a separate HDEPEND variable, since libraries are no longer glommed under DEPEND. RDEPEND, as always, is for runtime dependencies on the target.

What am I missing?
_________________
Personal overlay | Simple backup scheme
Back to top
View user's profile Send private message
sera
Retired Dev
Retired Dev


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Mon Feb 03, 2014 8:28 am    Post subject: Reply with quote

steveL wrote:
I cba to search the mailing-list to find it, but I distinctly recall the discussion. I quoted it on IRC at the time.


I repeat, a Java package declaring a subslot is a bug. Are you confusing slot operators with subslots maybe? And yes, I know you don't like ciaranm but that is utterly irrelevant here. Even more so as he did fight subslots for years.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Feb 03, 2014 5:13 pm    Post subject: Reply with quote

sera wrote:
I repeat, a Java package declaring a subslot is a bug. Are you confusing slot operators with subslots maybe?

Ah my bad, yes, slot operators then.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Feb 03, 2014 5:25 pm    Post subject: Reply with quote

Hypnos wrote:
Sorry, I don't understand your comment. Let me explain my understanding:

In FreeBSD, there are various *_DEPENDS variables for various Ports functions (patching, fetching, etc.). drobbins decided collapse all but of of them in DEPEND, with only RUN_DEPENDS left for RDEPEND. We find now that LIB_DEPENDS would have been useful to keep separate as well, to avoid haphazardly rebuilding broken dependent packages after a dependency is upgraded.

Then, with CDEPEND, we can specify additional tools needed on the build host. We don't need a separate HDEPEND variable, since libraries are no longer glommed under DEPEND. RDEPEND, as always, is for runtime dependencies on the target.

What am I missing?

CDEPEND is used for "common dependencies" so applies to both CBUILD and CHOST. Semantically there's no fit, and HDEPENDs do need special-handling, in that the mangler has to ensure they're installed to $ROOT/; otherwise they're the "same" as DEPEND. CDEPENDs are most often used for lib-dependencies, but that isn't necessarily the case: you might need a util at build-time and then at run-time too. For example, ed is a POSIX.2-mandated tool but not in @system. So it's muddy metadata atm.

CDEPEND does not need to be in the PMS, imo. We can use it easily from bash, or not: it's pure convenience.

There is also a case for HDEPEND, ofc, separate to LDEPEND: header-dependencies; by separating out the LDEPEND as you stated, the technically-correct HDEPEND (ie CHOST *not* CTARGET) also "feels" better for the case most users will need (this is important for development maintenance, though not as far as the PMS is concerned.) It'll also be used a lot less; as the HDEPEND bug indicated the overwhelming need is to separate out lib/link-dependencies, and it makes no sense not to simply call them LDEPEND (or some other suitable word) and be done: that way the mangler automatically knows it's a := dependency (if I've remembered it right), specified as one might expect, given the rest of the format.

So I shouldn't have said LDEPEND covers all three, my bad; it just covers the use-cases which are most important to end-users, and consequently also to upstream-developers. Hopefully you can see that a HDEPEND does not necessarily have to be present at runtime, and given an LDEPEND, would be simple and usually only for header-dependencies, but available for other use-cases without annoying toolchain folks. (I base the latter on conversation with #gcc on irc.oftc.net a few years ago: don't mix up CBUILD, CHOST and CTARGET if you go there;)
_________________
creaker wrote:
systemd. It is a really ass pain

update - "a most excellent portage wrapper"

#friendly-coders -- We're still here for you™ ;)


Last edited by steveL on Mon Feb 03, 2014 5:47 pm; edited 1 time in total
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Mon Feb 03, 2014 5:42 pm    Post subject: Reply with quote

Hypnos wrote:

As for multislot, I'm not yet convinced of its usefulness. Why do people need GRUB1 and GRUB2 simultaneously, or multiple minor versions of gcc ?


Because when the grub2 upgrade came around I wasn't ready to migrate, and to date I still haven't had time to study it and see why they took something simple and less error-prone to lilo (How many "li" boots, requiring rescue?) and made it apparently quite comples. At the same time I recognize that one of these days I ought to learn it, and maybe then it wll make more sense to me. When I get a round tuit.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
ulm
Developer
Developer


Joined: 04 Oct 2004
Posts: 98
Location: Mainz, Germany

PostPosted: Thu Feb 06, 2014 4:54 am    Post subject: Reply with quote

depontius wrote:
Hypnos wrote:

As for multislot, I'm not yet convinced of its usefulness. Why do people need GRUB1 and GRUB2 simultaneously, or multiple minor versions of gcc ?


Because when the grub2 upgrade came around I wasn't ready to migrate, and to date I still haven't had time to study it and see why they took something simple and less error-prone to lilo (How many "li" boots, requiring rescue?) and made it apparently quite comples. At the same time I recognize that one of these days I ought to learn it, and maybe then it wll make more sense to me. When I get a round tuit.

sys-boot/grub doesn't use dynamic slots. It has a multislot USE flag, but the flag doesn't affect the SLOT value (which is static, namely 0 for grub1 and 2 for grub2).
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Thu Feb 06, 2014 7:36 am    Post subject: Reply with quote

If developers want to test toolchain, they should copy the ebuild with a different slotname into their local overlay.
Just the same developers require from users in many cases (even in cases when ebuild maintainers could introduce a clean solution but don't do it for lazyness).
Breaking PMS just for developer's lazyness to copy development ebuilds to a local overlay is not acceptable.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Thu Feb 06, 2014 7:53 am    Post subject: Reply with quote

Suggestion: Please discuss *DEPEND in a separate thread. Although originally I wanted to comment, I resisted, because it does not really have to do much with the topic.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Feb 07, 2014 8:52 am    Post subject: Reply with quote

mv wrote:
If developers want to test toolchain, they should copy the ebuild with a different slotname into their local overlay.
Just the same developers require from users in many cases (even in cases when ebuild maintainers could introduce a clean solution but don't do it for lazyness).
Breaking PMS just for developer's lazyness to copy development ebuilds to a local overlay is not acceptable.

No, the point is to collaborate on those ebuilds with each other, and a few externals. As such, it's fine if they're hard-masked, and I see no reason at all why they can't have a gcc-multislot name, along with binutils-multislot and anything else they have to; somehow I doubt they need to multislot gmp, mpfr and mpc, but they should have the ability to do so for anything they choose, so long as they give up this idiotic demand for the mangler to change its cache, or the tree to be non-deterministic if you prefer.

Now it's just a question of whether pride makes them ignore a simple solution, because it is so simple and suggested by a user.

(Asked for thread split, will edit this and remove when it's done.)
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Fri Feb 07, 2014 9:57 am    Post subject: Reply with quote

steveL wrote:
No, the point is to collaborate on those ebuilds with each other, and a few externals.

This is why development in gentoo happens in experimental overlays. Why for the most sensitive part of gentoo, this overlay has to be in the main tree, even in a form which is known to be incompatible with the agreed standards for all packages?
As you said, another possible solution might be masking and having a separate :testing slot (if several versions need to be tested simultaneously even :testing-xxxx): This corresponds to the "natural" way of keeping an experimental overlay in the tree which does not break any standards.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Feb 07, 2014 9:05 pm    Post subject: Reply with quote

mv wrote:
This is why development in gentoo happens in experimental overlays. Why for the most sensitive part of gentoo, this overlay has to be in the main tree, even in a form which is known to be incompatible with the agreed standards for all packages?

Precisely because it is the most sensitive part: without it you don't have a tree; just a bunch of text files. As such it's the base for everything else. When they started using, it worked, and there wasn't any established standard, imo, irrespective of PMS; I'm with vapier in his overall response to some of that upstream.
Quote:
As you said, another possible solution might be masking and having a separate :testing slot (if several versions need to be tested simultaneously even :testing-xxxx): This corresponds to the "natural" way of keeping an experimental overlay in the tree which does not break any standards.

That'd be fine by me, I don't particularly care about this, apart from seeing it resolved in a way that enables everyone to collaborate, and hopefully stop toolchain being a frowned-upon area, which only makes it more obfuscated. Fewer bitchy rows on bugzilla would be nice ;)

That wouldn't fit in with the standard upgrade path, assuming there were a virtual for gcc-devel, something the current solution provides by default. Just saying; someone will be bound to raise it as an objection. ;) I'm happy to give that up, but personally I prefer the -multislot thing (or gcc-devel) because it's blindingly obvious what is intended. I'm big on clarity up-front: saves confusion down the line.
Separate naming makes everything else easy, since it's so easy to trigger from.

I'm thinking for update ofc, but the same applies to other external scripts. I hope we don't lose the excellent scripting ability (and focus) of emerge with change of team. You can be as clever as you want under the hood, but if we can't script with it, it may as well be windoze. Don't think we will, as dol-sen has done a lot of work on external tools, and their usage. Some of the team can be quite strong-willed, so it should be some fun popcorn ;-)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum